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 also have a long-running unit of work which is obviously not picking up the background change to the entity. Is there a way to force the unitofwork to hit the db when asked for this particular entity? I was wondering if there is some way to touch the entity in the unitofwork to tell the identitymap that the entity is stale and should be refreshed next time it is retrieved. I tried ensuring the trigger updated not only the entity property in question but also the UpdatedOn and LockVersion values. So does the unitofwork only hit the db if the id doesn't exist in the identitymap or does it also check UpdatedOn in the identitymap? I'm guessing not (ie it only hits the db for ids that it doesn't already have) as UpdatedOn and LockVersion are optional - yes? I know I can tell the unitofwork to flush on SaveChanges - will have to do that I guess... cheers justin PS - the reason I've got the trigger is because I'm maintaining an Entity.MostRecentOneToManyAssocEntityId property. Hasn't been as easy as I thought to keep this in sync via the model - any suggestions on how to do this nicely are welcome. :) |
|
|
You're right, UpdatedOn and LockVersion are not considered when determining whether we already have a copy of the entity. If we have something with the right ID, then we stick with that. There is currently no way to force an entity to update its values from the database. You must either use SaveChanges(true), or create a new unit of work and load it into that. This is a frequently requested feature but is problematic because of design issues around associations. |
|