This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
Hi. I seem to be running into an issue with a LINQ query that performs a projection onto an anonymous type. The data I'm accessing is extremely large, so it is very important that the query not materialize entity objects. If the anonymous type construction includes reference to a non-database object, the query automatically switches to full entity materialization mode. The following works just fine (the SQL selects the name only, no entities are materialized): from .... where ... select new { Name=Customer.Name }; The following does not work fine (the SQL selects ALL fields for customer, entities are materialized and running time is extremely slow): int age = 3; from .... where ... select new { Name=Customer.Name, Age=age }; Can anything be done about this? My current workaround is of course to add the field in a later stage - not optimal. Thanks! Shay |
|
|
When you see the behavior of "every column is selected, just like when we select the entity normally" when you are expecting a server side projection to occur, LightSpeed has made a determination that your projection cannot be handled server side. However a query like this:
Results in:
with the Age part being added in a client side projection afterward - so that would appear to match up with what you are doing? Are you able to recheck your query against the latest nightly and if this is still a problem can you send through a minimal repro project and I can have a look at what is going on here.
|
|
|
Thanks for the quick reply. What you describe is exactly what I expected should happen - Lightspeed adding the Age part in a client-side operation after the database query. This, however, did not happen. I tested both on Lightspeed 4 and on the latest nightly build. I will post a minimal repro project later today, thanks for your help! |
|
|
OK Jeremy, here's an ugly but working minimal repro project (using a different account, same person). If you observe the SQL logs, you will see that all the fields are being fetched and entities are being materialized, although the test code (function DoRealTest() in Program.cs) selects only one field in the projection. I've narrowed it down while reproducing... It seems the problem occurs only when the query performs two joins, as you'll see in the source code (as well as referencing an external non-database variable in the projection). Quite weird, hope it's no stupidity of some sort on my side... |
|
|
This is occurring because LightSpeed has determined that the projection cannot be executed server side. It is making this determination because in the LINQ expression there is a chain of selects occuring - first fetching an anonymous type containing Movie and Comment, and then an anonymous type containing that new type and Comment2 and then projecting out of that to fetch the .Title property. Ill add a backlog item to review improving this it would be more desirable to execute on the server side, but in order to do that we would need to do a lot more detection on how anonymous types are being used to know that we can project everything from entity origins. In the meantime you can get around this fairly easily by using the Querying API to fetch the server side bits and then use a client side select to append on the external variable as a secondary projection, e.g.
|
|
|
Thanks again for answering. I admit that from a user perspective it's quite weird and confusing for a feature to work with one join, and not with a second join (although I understand that internally this implies complications). My workaround is to project without the external type (avoiding the issue), and then project again manually in memory, adding my external field - it may not be pretty but it works, so no big blocker. Would be interested to hear about any developments. Shay |
|
|
One more comment: the same trouble happens with properties defined on the domain model - accessing a property seems to trigger the "fetch everything as entities" behavior. This makes it difficult to design and use proper object-oriented domain models and use them in projections. Thought to mention this because it's more compelling than the example of some external variable being used in the projection. |
|