RE: [Hibernate] RE: testing question

2005-08-09 Thread Steve Ebersole 
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
  createCREATE 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

Re: [Hibernate] RE: testing question

2005-08-09 Thread Max Rydahl Andersen 


the trimming were not about the CDATA, but about the definition.
Did not think about the mutally-exclusive choice thing - but we don't
do that normally, e.g. table and table.

/max


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

RE: [Hibernate] RE: testing question

2005-08-09 Thread Steve Ebersole 
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
  createCREATE 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

RE: [Hibernate] RE: testing question

2005-08-09 Thread Steve Ebersole 
Why a name, though?  I was not planning on allowing lookup of these
things as I don't see a benefit of allowing it.  Do you see a benefit to
it?  Hard to explain a configuration necessity that has no purpose...

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Christian Bauer
Sent: Monday, August 08, 2005 1:55 PM
To: Hibernate devel
Subject: Re: [Hibernate] RE: testing question


On Aug 8, 2005, at 8:48 PM, Steve Ebersole wrote:

 If anyone wants different name(s), speak now or forever hold your
 peace...

I think it should have a name= attribute so we keep a consistent  
catalog in the Configuration.



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

RE: [Hibernate] RE: testing question

2005-08-09 Thread Steve Ebersole 
Let's move this discussion over to:
http://opensource.atlassian.com/projects/hibernate/browse/HHH-840


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

RE: [Hibernate] RE: testing question

2005-08-09 Thread Steve Ebersole 
The binder code simply iterates the Elements, presumably in the order
they appear (I think that's how Dom4J works here).  But at any rate it's
the same question with multiple create/drop nested elements.  If Dom4J
does not for some reason return the Element iterator in the expected
order, it'll be the same issue...

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

Re: [Hibernate] RE: testing question

2005-08-09 Thread Christian Bauer 


On Aug 9, 2005, at 3:36 PM, Steve Ebersole wrote:


Why a name, though?  I was not planning on allowing lookup of these
things as I don't see a benefit of allowing it.  Do you see a  
benefit to

it?  Hard to explain a configuration necessity that has no purpose...


Not at the moment but I'm somewhat certain that a good example will  
present itself at some point :)




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

RE: [Hibernate] RE: testing question

2005-08-09 Thread Steve Ebersole 
What is the point of this for tooling if you cannot get the name of
these things, and even if you could you could not do anything to them by
name?

So maybe there is some requirement you need from this in terms of
tooling that you are not mentioning.  But as it stands I still see no
need for this.

-Original Message-
From: Max Andersen 
Sent: Tuesday, August 09, 2005 2:32 PM
To: Steve Ebersole; Hibernate devel
Subject: Re: [Hibernate] RE: testing question

mainly for tooling.

/max

 Why a name, though?  I was not planning on allowing lookup of these
 things as I don't see a benefit of allowing it.  Do you see a benefit
to
 it?  Hard to explain a configuration necessity that has no purpose...

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of
 Christian Bauer
 Sent: Monday, August 08, 2005 1:55 PM
 To: Hibernate devel
 Subject: Re: [Hibernate] RE: testing question


 On Aug 8, 2005, at 8:48 PM, Steve Ebersole wrote:

 If anyone wants different name(s), speak now or forever hold your
 peace...

 I think it should have a name= attribute so we keep a consistent
 catalog in the Configuration.



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

RE: [Hibernate] RE: testing question

2005-08-09 Thread Steve Ebersole 
huh?  we have no table/ element...

I'll check it in like this.  If you feel that strongly about it, feel
free to change it.

-Original Message-
From: Max Andersen 
Sent: Tuesday, August 09, 2005 2:20 PM
To: Steve Ebersole; Hibernate devel
Subject: Re: [Hibernate] RE: testing question


the trimming were not about the CDATA, but about the definition.
Did not think about the mutally-exclusive choice thing - but we don't
do that normally, e.g. table and table.

/max

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

Re: [Hibernate] RE: testing question

2005-08-09 Thread Max Rydahl Andersen 
On Tue, 09 Aug 2005 21:52:32 +0200, Steve Ebersole  
[EMAIL PROTECTED] wrote:



What is the point of this for tooling if you cannot get the name of
these things, and even if you could you could not do anything to them by
name?

So maybe there is some requirement you need from this in terms of
tooling that you are not mentioning.  But as it stands I still see no
need for this.


When I want to visualize or create a mapping.

Then it is very annoying to e.g. only see the following in a tree or list.

class name=Author
database-object
database-object
database-object
database-object

/max



-Original Message-
From: Max Andersen
Sent: Tuesday, August 09, 2005 2:32 PM
To: Steve Ebersole; Hibernate devel
Subject: Re: [Hibernate] RE: testing question

mainly for tooling.

/max


Why a name, though?  I was not planning on allowing lookup of these
things as I don't see a benefit of allowing it.  Do you see a benefit

to

it?  Hard to explain a configuration necessity that has no purpose...

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Christian Bauer
Sent: Monday, August 08, 2005 1:55 PM
To: Hibernate devel
Subject: Re: [Hibernate] RE: testing question


On Aug 8, 2005, at 8:48 PM, Steve Ebersole wrote:


If anyone wants different name(s), speak now or forever hold your
peace...


I think it should have a name= attribute so we keep a consistent
catalog in the Configuration.



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

Re: [Hibernate] RE: testing question

2005-08-09 Thread Max Rydahl Andersen 
On Tue, 09 Aug 2005 22:14:12 +0200, Steve Ebersole  
[EMAIL PROTECTED] wrote:



huh?  we have no table/ element...


i'm on crack.

column/column

/max



I'll check it in like this.  If you feel that strongly about it, feel
free to change it.

-Original Message-
From: Max Andersen
Sent: Tuesday, August 09, 2005 2:20 PM
To: Steve Ebersole; Hibernate devel
Subject: Re: [Hibernate] RE: testing question


the trimming were not about the CDATA, but about the definition.
Did not think about the mutally-exclusive choice thing - but we don't
do that normally, e.g. table and table.

/max


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

Re: [Hibernate] RE: testing question

2005-08-09 Thread Max Rydahl Andersen 


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

Re: [Hibernate] Re: testing question

2005-08-08 Thread Max Rydahl Andersen 


The trick below doesn't work well when you run the unittest standalone  
(which

I do constantly from inside eclipse)

/max


The reason for this instead of just
overriding setUp()/tearDown() would be to only execute this stuff when
we actually rebuild the session fatory.


I worked on the CaveatEmptor tests and I do this using the TestSetup  
decorator:


 public static Test suite() {

 TestSuite suite = new TestSuite();

 suite.addTestSuite( UserTest.class );
 suite.addTestSuite( ItemTest.class );
 suite.addTestSuite( CategoryItemTest.class );
 suite.addTestSuite( AuditTest.class );
 suite.addTestSuite( NestedSetTest.class );

 return new HibernateTestSetup(suite);
 }


public class HibernateTestSetup extends junit.extensions.TestSetup {

 public HibernateTestSetup(Test test) {
 super(test);
 // Enable automatic schema generation for unit testing, if not  
already set in configuration
 HibernateUtil.getConfiguration().setProperty 
(Environment.HBM2DDL_AUTO, create-drop);

 }

 protected void setUp() throws Exception {
 super.setUp();
 HibernateUtil.rebuildSessionFactory();
 }

 protected void tearDown() throws Exception {
 super.tearDown();
 HibernateUtil.getSessionFactory().close();
 }

}

This setup/teardown is executed once for the suite I'm wrapping.



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

RE: [Hibernate] Re: testing question

2005-08-08 Thread Steve Ebersole 
exactly

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Max
Rydahl Andersen
Sent: Monday, August 08, 2005 6:40 AM
To: Hibernate devel
Subject: Re: [Hibernate] Re: testing question


The trick below doesn't work well when you run the unittest standalone  
(which
I do constantly from inside eclipse)

/max

 The reason for this instead of just
 overriding setUp()/tearDown() would be to only execute this stuff
when
 we actually rebuild the session fatory.

 I worked on the CaveatEmptor tests and I do this using the TestSetup  
 decorator:

  public static Test suite() {

  TestSuite suite = new TestSuite();

  suite.addTestSuite( UserTest.class );
  suite.addTestSuite( ItemTest.class );
  suite.addTestSuite( CategoryItemTest.class );
  suite.addTestSuite( AuditTest.class );
  suite.addTestSuite( NestedSetTest.class );

  return new HibernateTestSetup(suite);
  }


 public class HibernateTestSetup extends junit.extensions.TestSetup {

  public HibernateTestSetup(Test test) {
  super(test);
  // Enable automatic schema generation for unit testing, if
not  
 already set in configuration
  HibernateUtil.getConfiguration().setProperty 
 (Environment.HBM2DDL_AUTO, create-drop);
  }

  protected void setUp() throws Exception {
  super.setUp();
  HibernateUtil.rebuildSessionFactory();
  }

  protected void tearDown() throws Exception {
  super.tearDown();
  HibernateUtil.getSessionFactory().close();
  }

 }

 This setup/teardown is executed once for the suite I'm wrapping.



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

Re: [Hibernate] RE: testing question

2005-08-08 Thread Max Rydahl Andersen 


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

RE: [Hibernate] RE: testing question

2005-08-08 Thread Steve Ebersole 
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

RE: [Hibernate] RE: testing question

2005-08-08 Thread Steve Ebersole 
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

Re: [Hibernate] RE: testing question

2005-08-08 Thread Christian Bauer 


On Aug 8, 2005, at 8:48 PM, Steve Ebersole wrote:


If anyone wants different name(s), speak now or forever hold your
peace...


I think it should have a name= attribute so we keep a consistent  
catalog in the Configuration.




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