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, We are currently evaluating Lightspeed for a new project we are working on. We have notice that on calling SaveChanges() on a unit of work many unchanged objects were getting saved back to the database. We eventually narrowed the issue down and found that we were changing a transient field on these objects, but not changing any of the database mapped fields. So it seems like Lightspeed is treating the object as changed even though the only changes are to fields that are not persisted to the database. Is this normal behaviour or is it likely that I am doing something wrong? Thanks Andrew |
|
|
|
|
Hi Andrew, This is a bug, kind of. LightSpeed marks all changes to the entity as resulting in a "Modified" state. This kinda makes sense from an "objects" point of view, because the object has changed, even if the change was to a transient field. But this flag is the same one that LightSpeed uses to determine whether the persistent state needs saving -- so it gets it wrong if only transient fields have changed. We've had a bit of a discussion around this and we're going to change this, so that an entity is marked as "Modified" only when you change a persistent field. This will mean that, as you would expect, LightSpeed will only save entities whose persistent fields have been modified. The fix will be in nightly builds dated 30 July 2009 and above. However, it does mean a change to the meaning of the Default and Modified states: Default will now mean that the persistent state is the same as the saved state, and Modified will mean the persistent state has been changed since the entity was loaded or last saved. The EntityState property will no longer reflect changes to the transient state. (This shouldn't affect you because you don't have existing code; I'm writing it up mainly as a documentation change.) Thanks for letting us know about this, and please let us know if the nightly build doesn't solve the problem for you! (Note: if upgrading from 2.2 RTM to a nightly build, please make sure to uninstall 2.2 RTM manually before installing the nightly. If you don't do this, you'll get errors next time you use the designer, and unfortunately the nightly installer doesn't yet detect this scenario. Future nightly-to-nightly upgrades should not require the manual uninstall.) |
|
|
|
|
Hi Ivan, Thanks a lot for sorting this out so quickly. It's very much appreciated. We will try out the nightly build tomorrow. Thanks Andrew |
|
|
|
