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 DatabaseO
en
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 .
Did not think about the mutally-exclusive choice thing - but we don't
do that normally, e.g. table and .
/max
ject
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 loo
huh? we have no 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
till 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
&g
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 som
, 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 j
ECTED]
[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 thi
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 lik
ehalf 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=&
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 ?)
I do though have some trimming suggestions:
CREATE INDEX ...
...
and
(don't see much
need for a separate ta
.
-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 ?)
I do though have some tri
n 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
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
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
The problem is:
statement.execute("CREATE OR REPLACE FUNCTION
allEmployments \n" +
"RETURN SYS_REFCURSOR \n" +
"AS \n" +
"st_cursor SYS_REFCURSOR; \n" +
: 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
, 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:
CREATE ...
CREATE ...
DROP
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
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
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 stand
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
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
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
24 matches
Mail list logo
