added a ConnectionDestination class

[abner]

added a ConnectionDestination class which receives s directly a java.sql.Connection. added a constructor to DbSetup with Connection as argument. The connection is wrapped in a ConnectionDestination instance

[jnizet]

Thanks for this contribution.

What is the use-case for this? In which situation do you need this functionality, other than simply letting DbSetup get the connection from a DataSource?

I don't really like the idea of passing an existing connection to DbSetup, and have DbSetup modify it (set autocommit to false) and close it, although it wasn't the one opening it in the first place. That seems wrong to me. Moreover, since I don't see when it's actually necessary to do this, I feel that this is something that should be left out of DbSetup: nothing prevents you (or anyone else) to use its own Destination implementation if needed.

[abner]

the use case is: i have test units using @RunWith(SpringJUnit4ClassRunner.class) which are transactional with rollback as default. So i get a Connection borrowed from a Hibernate Session Factory and want to pass that connection to DbSetup. I saw that dbSetup closes the connection. It is another point i think would be parameterized, so in case you provides the connection dbSetup should only executes statements above it and does not change the connection behavior nor closes it.

[jnizet]

Sorry, but that looks backwards to me. A Hibernate SessionFactory normally gets its own connections from a DataSource, just like DbSetup does. I don't even see any method in SessionFactory that allows getting a Connection from it. A Spring LocalSessionFactoryBean is typically configured using a DataSource (see http://docs.spring.io/spring/docs/4.1.x/javadoc-api/org/springframework/orm/hibernate4/LocalSessionFactoryBean.html#setDataSource-javax.sql.DataSource-), also declared as a Spring bean, and you should simply construct a DataSourceDestination from this same DataSource bean to use DbSetup.

[abner]

SessionFactory.currentSession().connection does the trick. Ok. But what is the approach if i want use dbSetup but i do want to have each of my tests not to commit the data to the database?

[jnizet]

You can choose to rollback the changes done by your tests, but what DbSetup inserts to the database is committed. Every setup should start by deleting everything from the database, as explained in the manual: http://dbsetup.ninja-squad.com/user-guide.html#dont-cleanup-prepare

[abner]

what about give dbSetup.launch an optional signature with a boolean parameter where the user would optionally ask for launch not to commit and not to close the connection? That will solve my use case.

[jnizet]

As I explain in the user guide, to me, not committing the data is an absurdity: it hides potential problems (deferred constraints not executing until commit, for example), and makes it very hard to debug a failing test, because you can never query the database while the test is running to see what it contains, why a query doesn't work, what it returns, etc.

Moreover, DbSetup doesn't use the same connection as the one used by the tests (since it gets one from the Destination, typically backed by a DataSource), so, if it didn't commit, the test wouldn't see the data inserted by DbSetup.

Not committing would also ruin the optimization provided by DbSetupTracker, which precisely consists in not doing anything if a test inserts the same data as a previous test which has not modified the database.

So sorry, but this request goes against the spirit of DbSetup, and brings more problems than it solves. If you want reproducible tests, you should start with an empty database anyway, so my advice is to clear it before each test, as explained in the manual.