I have read the docs and many posts in the forums and am still not clear on how to use transactions on contained entity collections when it comes to delete();

transaction.add(myEntity); - This will of course make this entity part of the transaction and all Save() operations on it will be part of the transaction.

myEntity.SomeField=1; //this is in a transaction myEntity.SomeCollection[0].AField=2; //this will be in an implicit transaction or the above contained transaction when using Save(True)

myEntity.Delete(); //what will this do? This will be in the transaction, right?

myEntity.SomeCollection[3].Delete(); //what will this do? Will it delete immediately? Do I have to explicitly use transaction.add(myEntity.SomeCollection) before I do the delete? Do I have to explicitly use transaction.add(myEntity.SomeCollection[3]) before I do the delete?

what about myEntity.SomeCollection[2].SomeCollection[1].Delete(); ?

Maybe since 'delete' operations are special and do not seem to work like 'save' when it comes to transactions - a note in the manual concerning deletes would be helpful?

The addition to the Transaction is not recursive, you should explicitly add entities or entityCollections to the tansaction object if you want the actions performed on these entities to participate in the specified transaction.

ok, so you are saying that I need to do this:

transaction.add(myEntity); transaction.add(myEntity.SomeCollection); transaction.add(myEntity.SomeCollection[0].AnotherCollection);

and then all delete() operations will not happen immediately and will wait the commit?

Yes.

Great thanks.

I still suggest something about delete() be put in the documentation. It is a bit confusing. Here is an example:

transaction.add(myEntity);
myEntity.SomeCollection.Add(someCollectionEntity);
myEntity.Save(true);
transaction.Commit();

The above works, and the 'SomeCollection' acts like it is in a transaction even thought the collection is not in a transaction - it is not committed until the commit statement. Compare that to very similar code, yet the collection code statements are executed immediately.

transaction.add(myEntity);
myEntity.SomeCollection[0].Delete();
myEntity.Save(true);
transaction.Commit();

Just a note in the documentation under the transaction entry talking about delete() and how it is immediate, how to include it, etc.

The confusion I think comes from the fact that saves are recursive, but deletes aren't. So with saves, if a parent is saved and it first has to save a related entity, that save is also in the same transaction.

Deletes aren't recursive, so every delete on an entity should be placed inside a transaction if required (as they don't 'inherit' the transaction from an entity which triggered their delete).

A note about this is indeed perhaps a good addition to the docs.

If you want to automate this, use a unit of work You can simply add the entities to delete to that object and call Commit() which will perform the work inside the transaction specified, no matter where the entities are located in the entity graph. Would that be sufficient in your case?

Would that be sufficient in your case?

I am actually fine with the above, no problems - just was lobbying for a note in the docs so it would be clear to me next time I forget.

Otis - Now that 2.6 is out the door, what are we to look forward to next?

WayneBrantley wrote:

Would that be sufficient in your case?

I am actually fine with the above, no problems - just was lobbying for a note in the docs so it would be clear to me next time I forget.

heh fair enough

Otis - Now that 2.6 is out the door, what are we to look forward to next?

V3 will sport a new designer, based on the old one (code when necessary is migrated, UI looks at places the same, but the rest is new) and will have model first development as well as the good old database first development type. We'll move away from binary files to a text-based DSL based entity modelling format, with the help of clever editors You will also be able to design visually in a visual DSL (not with vs.net's dreadful dsls but with our own wpf based stuff) and modifying the model with the visual editor will modify the text dsl and vice versa, undo-redo on the model level ( ) so it's pretty cool

The projects will consist of 3 parts: entity model, meta-data and mappings, and 4 target platforms will be supported (our own, nhibernate, linq to sql and entityframework), and a complete new code generation system + templates will be added, but I'll keep that under wraps for now, as I dont want others to steal the idea

We'll also add a quick model feature, which is something I wanted to do for a long time and which I think will be something people will be talk about for a long time. It has to do with the fact that you can interview your client and at the same time build the model, which is presented visually to you so the client can understand it too.

Stay tuned

Sounds great. One question:

Such a great new designer will of course have a ribbion UI - right?

LOL - Just kidding.

WayneBrantley wrote:

Sounds great. One question:

Such a great new designer will of course have a ribbion UI - right?

LOL - Just kidding.

hehe Of course! In pink