In working on this functionality to test the support for "database
generated" values, I ran across an interesting issue with unit testing
this functionality. Basically, the only real way to test this in a
consistent fashion across all databases is to apply triggers to the
database in use for testi
On Aug 8, 2005, at 1:08 PM, Steve Ebersole wrote:
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 s
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
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 Caveat
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
(
If we just let them register something like the DatabaseObject mentioned
(keyed by dialect) I guess I'm fine with that. Maybe something like:
Due to "export" feature, I guess DatabaseObject would really instead
need to expose the create/drop strings.
-Orig
And here MyTransactSQLTrigger would be a userprovided class that has
String[] createSQL/dropSQL methods ?
Sounds good.
I was more thinking like:
CREATE ...
CREATE ...
DROP ..
but I guess both are usable.
/max
If we just let them register something like the DatabaseObje
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,
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: Hibern
The problem is:
statement.execute("CREATE OR REPLACE FUNCTION
allEmployments \n" +
"RETURN SYS_REFCURSOR \n" +
"AS \n" +
"st_cursor SYS_REFCURSOR; \n" +
I didn't really understand that change. Why do we have several JARs
now for CGLIB and why can't we have a single one?
---
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Developm
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:
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
13 matches
Mail list logo
