Transient fields and EntityState

In LightSpeed 2.2, any change to an entity — at least, any change that goes through the Entity.Set method — results in the entity going into the Modified state. From the point of view of “has the object changed,” this makes sense, because the object state has indeed changed.

If the entity contains transient fields, however, things get a bit murkier. The trouble is that LightSpeed also uses the EntityState to decide whether an entity needs saving. So in LightSpeed 2.2, changing a transient field — if the change is made through the Set method — results in the entity being saved, even if none of its persistent fields have changed. This is clearly wasteful. It’s also a bit weird, because the entity goes back from Modified to Default even though no changes have actually been saved for it.

So we’re making a change in the nightly builds, so that entities will go into the Modified state only if you make a change that needs saving to the database. This will avoid unnecessary saves to entities with only transient changes. However, it does mean a slight change to the meaning of the Default and Modified states for objects with transient fields: the state will now reflect only the status of persistent fields.

In practice, this change is unlikely to affect you. If your entities don’t have transient fields, you won’t be affected at all. If you don’t use the EntityState property in your own code, you won’t be affected either. However, if you’re actively using the EntityState of entities with transient fields, and it’s important to you to capture cases even where the modifications won’t be persisted, please let us know. We’ll be happy to advise on alternative approaches, or to add support for your scenario, once we know what you’re trying to achieve.

Tagged as LightSpeed

Leave a Reply

Archives

Join our mailer

You should join our newsletter! Sent monthly:

Back to Top