Ah, I had been misunderstanding this as "DROP TABLE A; DROP TABLE B;", etc. Now that I better understand what you meant, I agree that this seems a better approach for #1 (unless others have any overlooked negatives to offer).
Steve Bohlen [email protected] http://blog.unhandled-exceptions.com http://twitter.com/sbohlen On Tue, Sep 6, 2011 at 10:51 AM, Patrick Earl <[email protected]> wrote: > With #1, I meant more like deleting entire classes of objects, like > tables, stored procedures, etc. The code would be something like > "list all user tables then delete them." I'm only aware of a few > reasons to do it this way. One is that in some cases, like on our > teamcity build server, and potentially in other enterprise situations, > developers may be given full access to a database, but may not be > given rights to freely create and delete databases. Another minor > reason is that we don't have to implement special connection string > parsing for each database type (potentially with different names of > parameters being used for the same purpose, etc). The final reason is > that if the user had set up any special permissions or objects to make > the database work with NHibernate, those would now be gone, for > example the uuid_generate_v4 function you can see in our current > TestDatabaseSetup code. > > Patrick Earl > > On Tue, Sep 6, 2011 at 6:20 AM, Stephen Bohlen <[email protected]> wrote: > > Isn't #1 exposing a potential maintenance headache in re: keeping this > > custom SQL synchronized with the DB objects? The present scorched-earth > > policy at least has the benefit of being certain there are no orphaned DB > > objects when run. What's the goal behind changing this? Speed/Perf of > > test-runs? Or other? > > > > #2 makes good sense to me. > > > > Steve Bohlen > > [email protected] > > http://blog.unhandled-exceptions.com > > http://twitter.com/sbohlen > > > > > > On Mon, Sep 5, 2011 at 10:03 PM, Patrick Earl <[email protected]> wrote: > >> > >> Regarding NHibernate.TestDatabaseSetup, I'm thinking of implementing > >> one of the two following things: > >> > >> 1. Instead of dropping and recreating everything, execute custom SQL > >> for each database to drop every known type of object created by the > >> tests. > >> 2. Just make the existing code more robust, so it handles different > >> databases specified by the connection strings. > >> > >> What do you guys think? > >> > >> Patrick Earl > > > > >
