I have three table I am populating (I have attached a diagram - ignore the Task table)

I create EntityCollection<T> for each type and populate them. The join table (TaskDefinitionSteps) gets the entities via the Navigators because the IDs for the other two tables are of course unknown at that point.

I put them in a UOW and Commit. I check the database and two of the tables are populated but the third is empty. I notice that I forgot to set the (non-nullable) Order field on the join table and run it again. Magic, all three tables populated and linked!! Brilliant.

I have two questions:- 1) My missing setting the Order field did not cause any errors, it just completely skipped writing the entities in that collection as though they weren't there (I checked the UOW after the Commit in the debugger and only the entities from the other two tables were in the entitiestoinsert field; also SQL Profiler showed no attempt to insert for them). What made the UOW decide to ignore these entities? I would have guessed it would have tried to insert the entities in case there was a default on the Order column.

2) Because these were all Inserts, I believe they all go in the same bucket. Is it then dependent solely on the order that each collection was added to the UOW that their contents are inserted? And the UOW makes no attempt to look at dependencies between those collections to determine the correct insertion order?

I'm not sure what you were doing as there is no code snippet.

But in general, if an entity has no changed/dirty fields, it won't be inserted nor updated, if that's what you are asking about.

Walaa wrote:

I'm not sure what you were doing as there is no code snippet.

But in general, if an entity has no changed/dirty fields, it won't be inserted nor updated, if that's what you are asking about.

Ok, further to this:

If I create a new entity then bind its fields it to a form then when the user clicks Save, it could be that some of the fields, e.g. some checkboxes, are not set (because the user wanted to leave them unchecked) causing the Save to fail. A validator working at the property level won't pick this up because there is no problem with the property values (false is this case).

So I could: 1) In the code where the new entity is created, set default values for every field. Not really keen on this since it can be error-prone. e.g. I add a new field and forget to locate every place in the app and add the default - I won't know about the issue until it crashes at runtime.

2) I can set defaults in the entity itself as it is created. Yes, but the 'IsDirty' would be set before the user has even seen it. May not be a problem though.

3) At the point of saving, have some code that 'pokes in' the default values for non-nullable , non-PK value fields. This might work well but is there an override I can add on CommonEntityBase at the write moment?

4) Have a validator that, when everything else is valid, does the 'poking in'.

5) Have a UOW do the same thing. Is there a hook I could use to do this?

6) Have the runtime library to the poking at the right point. It should be obvious that the Save is going to fail before passing it to the DB. Can't see Frans going for this "not the runtime library's job to check this - do it yourself!" - which is fair enough.

But which is the best way. Do you guys (or readers) have any thoughts?

Cheers Simon

You can use the Validation frameowrk (ValidateEntityBeforeSave is the method you need).