ORMBattle.NET

.

We're glad to see you here!

Do you need access to source code (@ Google Code - if so, send us your e-mail @ google), or we should write the tests for you?

.

.

I'm not familiar with EntityORM, so I'm not sure about exact code for it. But I can explain what SQL command sequence we expect per each test:

BEGIN TRAN
...Tested sequence must be executed here...
COMMIT TRAN

Since tested sequence is always composed of many commands, you can't rely on auto transactions. Moreover, if you will, you'll get just worse results. See SQL in this post for details: ormbattle.net/index.php/forum/11-everyth...t=20&start=20#33

Oh,

When I spoke in automatically or manual transactions I wanted to say in terms of leave the control to the developer.

In the EntityORM there is the SaveStatus class with the Start (means BEGIN TRANS in the database "world"); Finish (means COMMIT) and Cancel (means ROLLBACK).

If the developer omit the SaveStatus then when Save method of an entity object is executed then the framework automatically create an instance of SaveStatus and execute the Start method, do the batch sql opertions and in the end execute the Finish or Cancel methods of the SaveStatus instance.

If the developer create an instance of SaveStatus and execute the Start method before call the Save method then the framework ignore the save status and the developer is responsible to execute the Finish or Cancel method and even can execute anothe Save method of other entity object.

In other words the cases of the previous code corresponded to the same output but programmed differently.

Make all sense that there is better result by begin the trans once, do all the operations and commit or rollback once in the end.

In the case of EntityORM I would say that if there is a test for a group of operations with the same entity type or associations entity types then there is no necessary use of manual SaveStatus instance (makes the code more clean) and if there is a test with a group of non association entities than must be use a manual instance of SaveStatus to execute all the Saves and Finish in the end.

You agree ?

I'd prefer to see manual transactions I understand making the code more clear is good. But since here a lot depends on a particular ORM, ORM-specific code beautifying may lead to opposite effect: people might consider the test as suspicious.

DO4 can do nearly the same: you may not explicitly set transaction boundaries. In this case framework will automatically establish them. What exactly will happen depends on session configuration - e.g. any method call can be wrapped into individual transaction; it may just start it with the first call, but do not commit, and so on. But here we decided to avoid this at all. Just to not confuse the people.

What can be done: if you want to make the code looking more common, you can e.g. extract begin / commit transaction code into a special methods. I.e. anything similar is acceptable. Test must conform with the rules and be easy to understand. That's it.

Ok, understood.

Later, when the test code be completed I dispatch to you