Comments on: NHibernate unit testing with SQLite in-memory DB http://jasondentler.com/blog/2009/08/nhibernate-unit-testing-with-sqlite-in-memory-db/ I'm just here for the code Sun, 28 Feb 2010 13:09:05 +0000 http://wordpress.org/?v=2.9.1 hourly 1 By: Bill Bartmann http://jasondentler.com/blog/2009/08/nhibernate-unit-testing-with-sqlite-in-memory-db/comment-page-1/#comment-255 Bill Bartmann Wed, 02 Sep 2009 03:38:30 +0000 http://jasondentler.com/blog/?p=219#comment-255 Excellent site, keep up the good work Excellent site, keep up the good work

]]> By: How-To: Using the N* Stack, part 4 - NHibernate blog - NHibernate Forge http://jasondentler.com/blog/2009/08/nhibernate-unit-testing-with-sqlite-in-memory-db/comment-page-1/#comment-64 How-To: Using the N* Stack, part 4 - NHibernate blog - NHibernate Forge Sun, 16 Aug 2009 23:44:47 +0000 http://jasondentler.com/blog/?p=219#comment-64 [...] you haven’t already, grab the code for the SQLiteDatabaseScope class from my previous post. Add it to your data test [...] [...] you haven’t already, grab the code for the SQLiteDatabaseScope class from my previous post. Add it to your data test [...]

]]> By: Jason http://jasondentler.com/blog/2009/08/nhibernate-unit-testing-with-sqlite-in-memory-db/comment-page-1/#comment-63 Jason Sun, 16 Aug 2009 18:58:40 +0000 http://jasondentler.com/blog/?p=219#comment-63 @Tobin - I played around with the connection pooling options myself, but with that approach, I couldn't find a way to destroy the current database and build a fresh one. I even tried to use a system-generated password to trick connection pooling in to making a fresh DB. No dice. The primary purpose of the SQLiteDatabaseScope is to maintain a DB connection for the lifetime of the object, no matter what you do with your session(s). Now that I have a better understanding of Session.Clear, I'm not convinced it's necessary, but it's still nice to know exactly when I have a fresh DB and when I don't. @Tobin – I played around with the connection pooling options myself, but with that approach, I couldn’t find a way to destroy the current database and build a fresh one. I even tried to use a system-generated password to trick connection pooling in to making a fresh DB. No dice.

The primary purpose of the SQLiteDatabaseScope is to maintain a DB connection for the lifetime of the object, no matter what you do with your session(s).

Now that I have a better understanding of Session.Clear, I’m not convinced it’s necessary, but it’s still nice to know exactly when I have a fresh DB and when I don’t.

]]> By: Tobin Harris http://jasondentler.com/blog/2009/08/nhibernate-unit-testing-with-sqlite-in-memory-db/comment-page-1/#comment-62 Tobin Harris Sun, 16 Aug 2009 16:22:05 +0000 http://jasondentler.com/blog/?p=219#comment-62 Nice post. I'm pretty sure you can enable *connection pooling* so that your in-memory database doesn't go away once you close the connection. I've mentioned this on my blog post about NHibernate + SQLite testing http://tobinharris.com/past/2009/8/1/in-memory-sqlite-testing-with-nhibernate/ I don't bother with the connection pooling, I haven't seen the need for it yet (NHibernate is closing connections during the run of single test in my solutions). Like you, I am keen on having a fresh DB for each test too, I've even played with using a file-based sqlite db and doing a file-system copy of the blank db for each test - but it didn't perform (as you'll see on the blog post). Like the idea of being able to run tests in parallel, that's very neat. I don't quite see how the Scope adds additional value though? Maybe it's a kind of test-specific Unit of Work? I guess you want to control when connections are closed (so as not to lose your db!), but I've not seen any problems using the "create session/do work/commit work/dispose session" approach during SQLite in-memory testing. Anyway, I'm always interested in new ideas for this, Nice post.

I’m pretty sure you can enable *connection pooling* so that your in-memory database doesn’t go away once you close the connection. I’ve mentioned this on my blog post about NHibernate + SQLite testing

http://tobinharris.com/past/2009/8/1/in-memory-sqlite-testing-with-nhibernate/

I don’t bother with the connection pooling, I haven’t seen the need for it yet (NHibernate is closing connections during the run of single test in my solutions). Like you, I am keen on having a fresh DB for each test too, I’ve even played with using a file-based sqlite db and doing a file-system copy of the blank db for each test – but it didn’t perform (as you’ll see on the blog post).

Like the idea of being able to run tests in parallel, that’s very neat.

I don’t quite see how the Scope adds additional value though? Maybe it’s a kind of test-specific Unit of Work? I guess you want to control when connections are closed (so as not to lose your db!), but I’ve not seen any problems using the “create session/do work/commit work/dispose session” approach during SQLite in-memory testing.

Anyway, I’m always interested in new ideas for this,

]]> By: How-To: Using the N* Stack, part 4 « BASICly everything http://jasondentler.com/blog/2009/08/nhibernate-unit-testing-with-sqlite-in-memory-db/comment-page-1/#comment-58 How-To: Using the N* Stack, part 4 « BASICly everything Sun, 16 Aug 2009 09:06:08 +0000 http://jasondentler.com/blog/?p=219#comment-58 [...] About « NHibernate unit testing with SQLite in-memory DB [...] [...] About « NHibernate unit testing with SQLite in-memory DB [...]

]]>