HI,

Looking at LLBLGenProDomainService2 and the InsertEntity (UpdateEntity is the same), in the AddForSave the recurse parameter is set to true :

// SD.LLBLGen.Pro.RiaSupportClasses.LLBLGenProDomainService2
protected override void InsertEntity(IEntityCore toSave)
{
    this.UnitOfWorkToUse.AddForSave((IEntity2)toSave, null, !EntityCore<IEntityFields2>.MarkSavedEntitiesAsFetched, true);
}

I wonder why this is? In general its not a problem but there is a slight temporal oddity. If you have in the changeset a master and a detail entity, where there is an update to the master entity and an insert for a new detail entity, the InsertEntity happens first. After the call to InsertEntity for the detail entity, but before the call to UpdateEntity for the master entity, the UnitOfWork contains both entities, due to the recurse, and both have IsNew == true. This is normally not an issue as the UpdateEntity will reset the master entity IsNew = false before the UnitOfWork is persisted, but if I wanted to know if there was a good reason for setting it to true. In my scenario, in the UpdateEntity method I have code which will Save (but not commit obviously) the UnitOfWork and hence it attempts to insert a new master entity. I know its all dead code, RIA/Silverlight, but if you can remember the reason it would be good to know so I can decide whether its ok to override the method and pass false.

Thanks,

The recurse=true in that code simply says: save this entity and any new/dirty entities attached to it. It's common that you didn't add the child entities to the UOW at all, you just added the master entity. You could pass false to this method, but you would loose the child entities.

You should run a test with your specific scenario to see whether this fits your needs, etc.

That's not the case as the UpdateEntity for the master entity is called regardless so no changes are lost. Indeed its imperative that this is the case or else you will get 2 inserts, not an insert and an update.

this has been the case since the beginning and David has the right answer: the thing is that the entity inserted might have related entities attached, so to persist those, we set it to true so it recurses over the entity. This is the default for adapter, hence the flag being true.

Im not getting my point across clearly. The UpdateEntity happens anyway, so the recurse is not needed. Any related entities will get their InsertEntity/UpdateEntity methods called and indeed must have those methods called for reasons already stated. So I don't know why recurse is set to true.

However I appreciate you probably don't wont to spend much time on this so I'll override and set recurse=false.

Ah, understood: if there are related entities to the inserted entity, they'll get called anyway, so recursing the entities isn't really necessary, and as they're all added to the same UoW, the order is determined in the end still.

In that light, it's indeed odd that true is passed there. I have no real explanation for you as the initial commit had it already this way and in the design docs is no mention of it. I assume I simply specified 'true' as adapter recurses by default and I followed the same reasoning as David described earlier.

best indeed to override it and pass false to avoid the behavior you're running into. The ria services code is indeed not updated anymore, you can also decide to include it in your project and update it directly in the sourcecode.

Thanks, much appreciated