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
|
Lets say we retrieve all the "One" records from the database and detach them from the Unit of Work (for caching purposes). Now let's say we have 2 Many records which we directly link to the One record that has been detached (e.g. ManyRecord1.One = CachedOne; ManyRecord2.One = CachedOne;). The behavior we run into happens when we add 1 of the Many records to a (new) UnitOfWork (using .Add) and then call SaveChanges. Instead of inserting just one of the Many records (that has been Add-ed), both are inserted into the database. This is due to the link they share with CachedOne. While I understand how it finds the second Many-record, I do not understand why it's inserting that record. The link (Many->One) does not require the other Many record to be inserted. I know you can use the OneId (instead of the actual One entity) to insert, but between the creation of the Many record and actually inserting that record we use the .One property to retrieve info about the OneRecord. We also do not know if we should insert the Many record when its created (due to the checks happening after the creation). Now the question is, is it working as intended to have all Many records inserted even though only one is added to the unit of work. We currently use a work-around for the problem by specifying a Saving-event handler and canceling the save. |
|
|
When you write ManyRecord1.One = CachedOne, that brings CachedOne into ManyRecord1's unit of work (so that both sides of the association are part of the same UOW). Now when you write ManyRecord2.One = CachedOne, that brings ManyRecord2 into CachedOne's unit of work (again, so that both sides of the association are part of the same UOW) -- which is that same as ManyRecord1's UOW. So yes, both Many records end up in the UOW. You're suggesting we don't need to bring ManyRecord2 into CachedOne's unit of work. We do this so that in the more common case, where you do want to insert the child record, you don't need to explicitly Add the child record into the unit of work -- and so on across the graph of associations, so that you don't need to explicitly call Add for grandchildren, great-grandchildren, etc. So yes, it is working as intended. By adding ManyRecord1 to the UOW, you are adding its entire graph of associations to the UOW -- through CachedOne and on to ManyRecord2. You can't have an object graph part of which is included in the UOW and part of which isn't. |
|
|
Thank you for the clear explanation. |
|