Also, I guess a note about the ordering of the statements is in order. So the Configuration maintains a list of the <database-objects/> bound. For the create script it appends them unto the end of the current processing. For the drop script it adds them to the beginning.
So I assume you are referring to the ordering amongst the different <database-object/>s, which is my previous answer... Overall, for large mapping sets, I basically envisioned this as being done in a separate mapping file just like we suggest for things like cache strategies, etc anyway. The only "fool-proof" way to achieve this is to introduce a notion of dependencies, which I don't think we want to get into. That's my $.02 at any rate. P.S. I choose <database-object/> because in my setup, that's what you are defining: one database object. -----Original Message----- From: Max Andersen Sent: Tuesday, August 09, 2005 5:58 AM To: Steve Ebersole; Hibernate devel Subject: Re: [Hibernate] RE: testing question i don't like database-object, but I don't have a better suggestion, so...(maybe just <ddl> ?) I do though have some trimming suggestions: <database-object name="blahBlah"> <create>CREATE INDEX ...</create> <drop>...</drop> <scope dialect="org.hibernate.dialect.Oracle9Dialect"/> </database-object> and <database-object name="blaBlah" class="MyPLSQLTrigger"/> (don't see much need for a separate <definition> tag for the class) btw. the reason for my wish for multiple create/drop's were simply to allow grouping of these construct to ensure proper ordering. Can we guarantee that with single drop/create's ? /max > So I have this implemented locally. It actually uses the > org.hibernate.mapping.RelationModel interface. It allows definition > through the mapping file or programmatically via the Configuration. > There are two basic usages: > > #1: > <database-object> > <create> > <![CDATA[CREATE OR REPLACE TRIGGER t_iu_gen_prop > BEFORE INSERT OR UPDATE ON gen_prop > FOR EACH ROW > BEGIN > IF INSERTING THEN > :new.lastModified := HEXTORAW( '1' ); > ELSE > :new.lastModified := HEXTORAW( > TO_NUMBER( RAWTOHEX( :old.lastModified ) ) + 1 > ); > END IF; > END;]]> > </create> > <drop> > <![CDATA[DROP TRIGGER t_iu_gen_prop]]> > </drop> > <!-- again, completely optional --> > <dialect-scope name="org.hibernate.dialect.Oracle9Dialect"/> > <dialect-scope name="org.hibernate.dialect.OracleDialect"/> > </database-object> > > #2: > <database-object> > <definition class="MyPLSQLTrigger"/> > <!-- again, completely optional --> > <dialect-scope name="org.hibernate.dialect.Oracle9Dialect"/> > <dialect-scope name="org.hibernate.dialect.OracleDialect"/> > </database-object> > > If anyone wants different name(s), speak now or forever hold your > peace... > > Steve > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Steve > Ebersole > Sent: Monday, August 08, 2005 8:01 AM > To: Hibernate devel > Subject: RE: [Hibernate] RE: testing question > > Actually, probably even better: > > public interface DatabaseObject { > public String sqlCreateString(); > public String sqlDropString(); > } > > ;) > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Steve > Ebersole > Sent: Monday, August 08, 2005 7:54 AM > To: Hibernate devel > Subject: RE: [Hibernate] RE: testing question > > Yes, but I was more thinking: > > public interface DatabaseObject { > public String getCreateCommand(); > public String getDropCommand(); > } > > because the CREATE/DROP SQL commands explicit operate on a single > database object... > > -----Original Message----- > From: Max Andersen > Sent: Monday, August 08, 2005 7:49 AM > To: Steve Ebersole; Hibernate devel > Subject: Re: [Hibernate] RE: testing question > > > And here MyTransactSQLTrigger would be a userprovided class that has > String[] createSQL/dropSQL methods ? > > Sounds good. > I was more thinking like: > > <database-object name="WhateverMostlyForLogging"> > <create-ddl> > CREATE ... > </create-ddl> > <create-ddl> > CREATE ... > </create-ddl> > <drop-ddl> > DROP .. > </drop-ddl> > </database-object> > > but I guess both are usable. > > /max >> 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 > > > > > ------------------------------------------------------- > 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 > > > ------------------------------------------------------- > 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 > > > ------------------------------------------------------- > 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 ------------------------------------------------------- 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
