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
|
Hello, we have just found that on entities created from a DistributedUnitOfWork, the property UnitOfWork is null, even if you call uow.Attach(entity). Looks like a bug, but not sure, just letting you people know :) Regards! Vicente |
|
|
Hi Vicente, This is currently by-design as there are some unwanted side-effects that occur if it does have a UnitOfWork associated that we need to iron out before we can get this baked in. The entity is still being tracked by the UnitOfWork however as it is in the identity map. Calling Attach adds the entity in to the identity map, so it is still doing the same thing even if the result is slightly not what you would expect :)
Jeremy |
|
|
Hi Jeremy, ok. We needed this because we needed something like a ThroughAssociation and we thought about doing it by creating a property and using the UoW of the entity to perform a query. So next question wold be, how do ThroughAssociations work in a distributed sceneario? Regards, Vicente |
|
|
They work as they do on the server except you will need to ensure the data is serializable (DataMember attributes applied correctly) and loaded at the time of serialization (Using eager loading). So for example you would set up the ThroughAssociation as normal in your model. Lets say you have a scenario with two entity A and B and a through entity called M. You have a 1 to many from A to M and from B to M. If you want to enable your ThroughAssociation for both ends you will want to set the following properties on both of the associations:
If you are only interersted in fetching B's from your A entity (a uni-directional use of the ThroughAssociation) then you will need to set the following on the A->M assocation:
And then the following on the B->M association:
This sets up the appropriate set of eager loads to fetch the data and ensures the data will be serialized for each association in the chain.
Jeremy |
|
|
Mmm, I don´t have exactly the scenario you describe, in my case I have a 1-many association from A to M and a 1-many association from M to B. And I want to get all the B from A (like a SelectMany in LINQ). This was the query I was using in A to do it (before discovering the UoW been null): return this.UnitOfWork.Find<B>(Entity.Attribute("M.AId") == this.Id); ThroughAssociations work for this case or they are only to help in N-M associations? |
|
|
Yes, this is not a ThroughAssociation case then. ThroughAssociations are for many to many relationships where you want to go through the intermediary table to the entities on the other side. For the situation you are dealing with you could tackle this in a couple of ways. Either you could perform a SelectMany (either as part of your property code - e.g. Ms.SelectMany(m => m.Bs); or where you would be calling your property e.g. var BsInA = a.Ms.SelectMany(m => m.Bs); For these cases you would need to ensure you are eager loading so that the objects are available at the client. Alternatively you could implement a method rather than property for this and pass in the DistributedUnitOfWork instance and then your original code would be applicable (substituting this.UnitOfWork with your supplied UnitOfWork instead).
Jeremy |
|
|
Hi Jeremy, I don't understand one thing: why is eager loading necessary? I mean, if is not eager-loaded, that means no data will come to the client if I try to perform the SelectMany over it? What's the difference between doing it over a UnitOfWork? (I would be expecting both alternatives to produce the same result in the end). Regards, Vicente |
|
|
It isnt necessary, but we would recommend it. If you are running the SelectMany against the client side collections then they will already need to be loaded which is they needed to be marked up with a [DataMember] attribute so they will be serialized. The use of the EagerLoad is not strictly required, it would work without, but it does mean you will start generating a lot more queries due to serialization asking for the data on those properties so we would certainly recommend you look at using eager loading (also look at the use of named aggregates to scope when those eager loads occur) to allow the entity and the associations you need to be fetched in a single query. If you are running the SelectMany as part of a query which is rooted on the UnitOfWork (e.g. UnitOfWork.MyEntities.SelectMany()) then this isnt relevant since the data would just be returned as requested at the time. Possibly one thing that might be misleading you on this is that for now there is no lazy load behavior, so once you have grabbed an entity and its associated [DataMember] associations then you cant subsequently load other associations that were not part of that contract. Not sure if that is the case with the way you have your model set up?
Jeremy |
|