I have a problem with a deployment scenario. The database (SQL Server) is in Europe and the server (where LLBLGen runs) is in Singapore. I expect to get some latency and that's fine. However, with a big LLBLGenProQuery and lots of WithPaths it's made worse because every path incurs the latency cost. Ideally I'd like to execute the whole query including all it's WithPaths/SubPaths in one trip by providing an endpoint near the database which would return the EntityCollection (and all its children) in one go. The obvious first thought is to send the LLBLGenProQuery over the wire, but it is not serializable.

Any ideas? Can LLBLGenProQuery be converted to a RelationPredicateBucket for example?

Thanks,

Scott

Prefetch paths are executed only after a set has been fetched so serializing the prefetch paths won't help, you need a joined set which is projected to entities. Our runtime doesn't support projecting a joined set to a graph of entities. It can do so with DTOs/derived models but not for entities.

I'd like to discuss this a bit more. A joined set is not going to be feasible for some cases, where I've a lot of of subpaths, where filters, its going to bloat the payload with repeated parent columns too much.

I'm not sure I am convinced that it is not possible to serialize a LLBLGenProQuery<T>. I'm going to investigate, but the principal is that given a method

public EntityCollectionBase2<T> FetchCollection<T>(IQueryable<T> q, [CallerMemberName] string methodName = "caller not specified") where T : EntityBase2

That returns an EntityCollection, when that method returns, all of the prefetches have been done, after each parent set is returned. So if you could serialize q you could remote that method call and it would be one round trip. I.e. this code

((LLBLGenProProvider2)q.Provider).AdapterToUse = tsw.DataAccessAdapter;
var c = ((ILLBLGenProQuery)q).Execute<EntityCollectionBase2<T>>();

will execute all the queries. PrefetchPathElement2 itself is serializable, so maybe if I extract the prefetch paths out from LLBLGenProQuery<T> wrap them in some new tree structure that is serializable.... ?

A linq query isn't serializable, sadly. It's an expression tree which has to be rebuilt on the other side. We made objects needed for Unit of work xml serializable but that's not going to help you here.

Besides that, if the query was serializable, what would deserialize it and run it? If that's a service close to the DB, wouldn't it be better to implement an interface on the service which accepts elements so you can build the query with the prefetch paths on the service side? the low-level API could be utilized here if the service runs on .net framework, but I think that's the only route here as linq queries aren't serializable due to their nature. We didn't make queryspec serializable because linq queries aren't serializable either (so the use cases aren't there, people won't use it) because most people will use a higher-level service which builds the query on the service side based on input.

Thank you for the reply. Ok, I'm getting that attempting do my own serialization of the linq query is not a good idea. And I understand your last point that this is not a common scenario and there wont be many users who want it. Your suggestion of remoting the call above the linq generation is good, thank you for that, sometimes it just needs someone not stuck in the problem to get you started. LLBLGen is a very good product!

Will close the thread.