And the reason I did "definition" as a separate nested element was so that I could enforce this as a mutually-exclusive choice in the DTD. In DTD I can say "this nested element OR those other two nested elements".
Plus, you realize that there is no trimming involved at all in your first example compared to my first example, right? I simply chose CDATA tags to enclose my text, where you did not... -----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
