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, is there any way to know if a unit of work will perfom any work when calling Save? (that's it, it has an entity attached with changes that need to be saved in the database). I have been searching and I found a thread about tracking the changes on the entities (http://www.mindscape.co.nz/forums/Thread.aspx?PostID=7492) but that seems a little overkill for us, we just need to know if there's a change, not the exact changes. Any idea on how to perform this? Regards, Vicente |
|
|
unitOfWork.Any(e => e.EntityState != EntityState.Default) |
|
|
Thanks, going to try to see how fast it peforms (it's to databing against a ICommand to know if the user can save or not, so it's important that is not horribly slow for a big number of entities). |
|
|
Ivan, It appears that in some cases, a new entity that is added to a collection whose owner is attached to a UnitOfWok is not represented in the IEnumerable that the UnitOfWork represents. LightSpeed does however do the work to persist the new entity. It is almost as if there is some "deferred add entity to a unit of work" behavior going on. Is this possible? This defeats the ability to use this cool new feature to do effective dirty tracking. |
|
|
There *shouldn't* be any such behaviour: the enumerator and the persistence engine work off the same set of entities. Are you able to pin down a repeatable repro? We would be very interested to see it. |
|
|
Thanks for looking into this! Truly, your support is second to none. I was able to reproduce the issue. Please see the attached repro. |
|
|
Any luck with diagnosing this? |
|
|
We've reproduced the issue and have a candidate fix, which will be in the 21 April nightly build, available from about 1500 GMT. We have noted a potential compatibility issue as this changes the behaviour of FindById for IDs that are in memory but not in the database. However, we believe the old behaviour was incorrect and the new behaviour is correct. Please let us know if you see any compatibility issues. (I expect to be able to get round to your other issue tomorrow -- sorry, the VS2010 work has been holding things up and has taken a lot longer than expected.) |
|