If we just let them register something like the DatabaseObject mentioned
(keyed by dialect) I guess I'm fine with that. Maybe something like:
<database-object class="MyTransactSQLTrigger ">
<!-- optional "dialect scoping" -->
<dialect class="o.h.d.SybaseDialect"/>
<dialect class="o.h.d.SQLServerDialect"/>
</database-object>
<database-object class="MyPLSQLTrigger">
<!-- optional "dialect scoping" -->
<dialect class="o.h.d.OracleDialect"/>
<dialect class="o.h.d.Oracle9Dialect"/>
</database-object>
Due to "export" feature, I guess DatabaseObject would really instead
need to expose the create/drop strings.
-----Original Message-----
From: Max Andersen
Sent: Monday, August 08, 2005 6:36 AM
To: Steve Ebersole; [EMAIL PROTECTED]; Hibernate devel
Subject: Re: testing question
>
> This is the same reason why I always get failures on the tests
relating
> to stored procedure support.
>
These tests creates the SP's before testing - thus if you get errors
while
running
junit test then that is something that should be failing.
How about simply extending hibernate with the possibility for user
provided additional DDL's ?
(been suggested before by users, but not had any compelling usecase for
it...maybe our own
testing is ?)
/max
> I think we should come up with a unified way to approach this. So
I'll
> throw out my proposal as a starting point and see if anyone has better
> solutions.
>
> The basic idea is to have the individual tests in this category
register
> "additional db objects" with the base test case class; these would be
> used during setUp() and tearDown() processing. DatabaseObject might
> look like:
>
> interface DatabaseObject {
> void doCreate(Connection conn);
> void doDrop(Connection conn);
> }
>
> I am thinking of a new test base class that tests relying on non-table
> db-object creation could extend; or even add this functionality to the
> existing TestCase. It would add a single new method "DatabaseObject[]
> getAdditionalDatabaseObjects(Dialect dialect)" which it would call
> during setUp() processing. The reason for this instead of just
> overriding setUp()/tearDown() would be to only execute this stuff when
> we actually rebuild the session fatory.
>
> The simple option would be to have each test class do this work
> themselves in setUp() and tearDown() for each test execution even
though
> we are not necessarily creating/dropping the schema at that frequency.
>
> Anyway, thoughts?
>
> Steve
>
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
hibernate-devel mailing list
hibernate-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hibernate-devel
