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
>
>
