Clarification on modifying entity and marking field as "changed"

Posts   
 
    
Gabbo
User
Posts: 56
Joined: 12-Jun-2006
# Posted on: 12-Sep-2006 23:13:23   

Hi,

If I'm trying to update an entity using Option 2 under the Modifying an entity section of the documentation (creating new entity, setting primary key, and setting IsNew = false, and setting any additional fields), a note states that "Setting a field to the same value it already has will not set the field to a value (and will not mark the field as 'changed'), unless the entity is new."

If this is the case, it seems that the entity itself shouldn't be marked as dirty if the above conditions apply? This is a question because the entity is marked as dirty, even if the fields are identical. I've seen several similar threads pertaining to what triggers a dirty entity. I'm trying to avoid writing a condition for each and every field I set when assigning values from a web-based form.

if ( oldValue1.Trim() != newValue1.Trim() ) entity.Field1 = newValue1.Trim();

if ( oldValue2.Trim() != newValue2.Trim() ) entity.Field2 = newValue2.Trim();

I only want an entity to be marked as dirty when a value changes (I set modification related fields when an entity is dirty), and it's extremely repetitive code to write this type of condition each and every time.

Is there a better way?

Thanks in advance!

bclubb
User
Posts: 934
Joined: 12-Feb-2004
# Posted on: 13-Sep-2006 05:20:26   

To do what you are wanting you should use option 1 instead. The purpose of option 2 is to allow you to update an entity without having to first fetch it.

You want to only execute your update if there is an actual change. To do this you need to fetch the entity first. Once you have done that you can set it's properties. If none of those properties are assigned new values then the entity will not be dirty. If you do change the value of any properties then those values will be updated in the database.

Gabbo
User
Posts: 56
Joined: 12-Jun-2006
# Posted on: 13-Sep-2006 17:28:49   

bclubb wrote:

To do what you are wanting you should use option 1 instead. The purpose of option 2 is to allow you to update an entity without having to first fetch it.

You want to only execute your update if there is an actual change. To do this you need to fetch the entity first. Once you have done that you can set it's properties. If none of those properties are assigned new values then the entity will not be dirty. If you do change the value of any properties then those values will be updated in the database.

Thanks for the reply. At first I thought this was promising for not having to wrap each assignment in conditional code. Unfortunately "empty" fields set an entity to IsDirty. I've tried assigning both an empty string and a null, but in both cases, the entity is still updated to IsDirty. If both fields have values, and the values are equal, it doesn't mark the field as dirty even though I've assigned it. A standard scenario might be a middle name, which is left NULL or EMPTY in most cases. Without wrapping each assignment with a conditional, the entity will be marked dirty, even if this field hasn't changed.

It would be nice if there was some kind of empty field assignment that indicated the field hasn't really changed. Null would be a natural now that V2 supports nullable fields, but I know there's at least one other thread that covers the thinking behind why this is a bad thing. So for now I guess I get used to:

if ( oldValue1.Trim() != newValue1.Trim() ) entity.Field1 = newValue1.Trim();

if ( oldValue2.Trim() != newValue2.Trim() ) entity.Field2 = newValue2.Trim();

...

if ( oldValue34.Trim() != newValue34.Trim() ) entity.Field34 = newValue34.Trim();

Walaa avatar
Walaa
Support Team
Posts: 14995
Joined: 21-Aug-2005
# Posted on: 14-Sep-2006 07:14:58   

Null and empty string are treated differently in some databases (eg. SQL Server) So if a field is null and you set it to empty string... it's marked as changed. And the opposite is correct too.

You may also go for option 1 as Brian have suggested.