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
|
From the attached model, when I try to load "Purchases" along with "Product" and "Account" information (aggregate names "ProductInfo" and "PurchaserInfo") using the following syntax, only second WithAggregate wins and no matter which aggregate names comes before the last, it is not loaded: var query = from sales in uow.Purchases Above query loads Purchase + Account data and If I switch the WithAggregates above, it will load Purchase + Product data, but not all three of them (Purchase + Account + Product). If you need me, I think I can provide a sample model and failing unit tests. |
|
|
As a workaround, for now, I've marked those relations with "Eager Load Collection = True", but it doesn't solve the problem, as I just need to load those in some cases, not always. BTW, forgot the model screenshot, which is added now.
|
|
|
We currently support only a single aggregate per query. This was more obvious in the core API; we should probably have detected this condition in the LINQ operator and raised an error for it. Longer term, we might look at enabling a query to load multiple aggregates, but this probably won't happen in the short term (we'll want to think about your suggestion for fine-grained eager loading first). The solution to this is a rather ugly one: define three aggregates, ProductInfo, PurchaserInfo and ProductAndPurchaserInfo. Place ProductInfo and ProductAndPurchaseInfo on the Product association, and PurchaserInfo and ProductAndPurchaserInfo on the Purchaser association. And in the query above, specify the ProductAndPurchaseInfo aggregate. Why do we have an API that makes this scenario so ugly? Because of different query usage philosophies. Our aggregate concept is designed around the assumption there will typically be a few "standard" aggregates that emerge naturally from the domain analysis. In your scenario, however, you want more fine-grained, ad-hoc control over exactly which associations are loaded for any given query. Faced with the latter design philosophy, aggregates do indeed get ugly and run into the dreaded combinatorial explosion. On the other hand, when there are a relatively small number of standard eager-load sequences, each of which may contain several associations and involve multi-table traversals, aggregates are simpler and easier to maintain at the point of query, compared to specifying every eager-load sequence explicitly on every query. We went for the aggregates approach because we've found the latter pattern to be more useful in the applications we've built. Of course, as you note in a previous thread, this doesn't have to be an either-or: we could add a further API to handle ad-hoc aggregates; it's just a matter of finding the time! |
|
|
Okay....now I understand the reason behind aggregates approach. Yet, for the time being that this scenario is not supported, an error indicating the wrong usage would be good enough. |
|
|
Is there any way to say "don't load anything (fields, associations) unless they are in this named aggregate?". I think that would come closest to the projection idea I've been struggling with for a while. Basically I just want to load a couple fields from two joined tables and everything else is superfluous.
Thanks!
James
|
|
|
No, that's not possible. Field that are capable of being lazy loaded must be marked up as such (paradoxically, with the [EagerLoad] attribute). So you would need to mark up your two fields with [EagerLoad("MyName")] and everything else with [EagerLoad] (optionally with some other aggregate); which you can do, of course, but it involves explicitly excluding all the other fields from loading by default. |
|