hibernate-devel — development

Re: [Hibernate-devel] Mismatch MappingByReflection/Mapping DTD

[Doug C. <de...@fl...>]

> In a
> <many-to-one name="address" column="address" type="net.amoeller.eg.om.Addres
s"/>>
> the "type" attribute has to be a "class" attribute.

Thank you for the report; it's now fixed in the cvs.

e

Re: [Hibernate-devel] building cvs version

[Christoph S. <ch...@sc...>]

Gavin_King/Cirrus%CI...@ci... wrote:

>>but all the libs that are needed are not in cvs.
>>
>
>ah hmmmmm this is common practice, isn't it.....
>
>sorry i'm kinda new to CVS.
>
some people put even ant into the cvs, together with a file that starts 
it. Not sure if thats a good idea. But it is common practice that all 
libs that are needed to build are included in cvs, which makes a lot of 
sense, because sometimes code changes need a new version of a lib too, 
so its always a good idea to track library versions together with code 
versions.
Especially xalan and xerces are candidates for jars where you need the 
exactly right version.

>
>The libs you need are:
>
>JDOM ( www.jdom.org )
>Xalan/Xerces ( xml.apache.org )
>
>Theres one class which also needs javax.sql.Datasource but don't worry if
>that class won't compile (you can run without it).
>
>oh .... and do a cvs upd (i just fixed a bug) ;)
>
ok :)

>
>
>_______________________________________________
>Hibernate-devel mailing list
>Hib...@li...
>https://lists.sourceforge.net/lists/listinfo/hibernate-devel
>
>

Re: [Hibernate-devel] building cvs version

[Gavin_King/Cirrus%<CI...@ci...>]

> but all the libs that are needed are not in cvs.

ah hmmmmm this is common practice, isn't it.....

sorry i'm kinda new to CVS.

The libs you need are:

JDOM ( www.jdom.org )
Xalan/Xerces ( xml.apache.org )

Theres one class which also needs javax.sql.Datasource but don't worry if
that class won't compile (you can run without it).

oh .... and do a cvs upd (i just fixed a bug) ;)

[Hibernate-devel] building cvs version

[Christoph S. <ch...@sc...>]

Hi people!

Is there documentation somewhere how to build Hibernate from cvs? I 
checked it out, but all the libs that are needed are not in cvs. Is 
there a reason for that?

regards
 chris

[Hibernate-devel] Mismatch MappingByReflection/Mapping DTD

[Andreas M. <amo...@am...>]

Hi,

I used the CVS-HEAD version from 22-02-2002 of hibernate. Generating a
mapping from my classes whith MappingByReflection and using that
mapping to export a schema with DBSchemaExport I discovered a mismatch
between the mapping and the DTD.

In a=20
<many-to-one name=3D"address" column=3D"address" type=3D"net.amoeller.e=
g.om.Addres
s"/>
the "type" attribute has to be a "class" attribute.

As intended the MappingByReflection tool gives you a good start; nice
tool.=20

Btw. is somebody out there using hibernate in a production env?

Keep up the good work!

Regards

--=20
Andreas M=F6ller:  amo...@am...
                 http://www.amoeller.net
Software Design und Entwicklung

[Hibernate-devel] hibernate bug in JDK 1.4

[Gavin_King/Cirrus%<CI...@ci...>]

A bug first reported by Gwenn and then later by Doug has now been fixed. I
tracked it down to a difference between the IBM 1.3 JVM that I have been
testing on and the Sun 1.4 JVM. The Sun behaviour is consistent with JDK
1.2 javadocs, so I'm not sure what's going on with IBM.

Basically, conversion of an argument of java.lang.Method.invoke() to a
primitive type is supposed to throw an IllegalArgumentException but on some
platforms it throws a NullPointerException instead. Hibernate was expecting
a NullPointerException.

In other news:

(1) I have rewritten the collections code and fixed some problems.
(2) I have implemented atomicity of Session methods. Any invocation upon
the session should now leave the session in a consistent state, even if it
raises an exception (this requires some machinery, since the session is
extremely reentrant). There is a performance cost to this, so it might be
worth being able to turn this feature off, since most applications won't
use it.

I am happy to release version 0.9.6 now.

Gavin

[Hibernate-devel] Re: clustering support

[Gavin_King/Cirrus%<CI...@ci...>]

> thanx 4 your prompt reply.

NP, we are in same timezone :)

> regarding the HiLoGenerator, there were two things.
> 1. the sychronised block through me - which u have explained already
> 2. i wasn't sure if the RDBMS would hold a lock between the select and
the
> update.  (whenever i have had to this in the past it has been through
stored
> procedures where the locking was explicitely specified.)

True, this all depends upon your transaction isolation level.

Read Committed + Read Uncommitted: broken, you can't use HiLoGenerator
Repeatable Read + Serializable: works fine. (Very) slight risk of a
transaction rollback

Of course, there is only a slight risk of two machines reading the HiLo
table simultaneously. There are many other much bigger dangers in using
read committed as your isolation level. However, for certain kinds of
applications read committed is often used (and stupid oracle doesn't even
support repeatable read).

hmmmm...I suppose it also breaks HiLoGenerator if you turn off transactions
and use optimistic locking!

Okay then. Possible solutions:

(0) simply document the fact that HiLoGenerator is meant to be used where
the isolation level is at least repeatable read. (otherwise use the UUID
generator)
(1) use a select for update. but "for update" is not supported on all
platforms (specifically not sybase, one of my favorites)
(2) add a where clause to the update "update hilo set next=10 where next=9"
and retry if no rows are updated.

I will implement (2) it seems like a good solution.

I am ccing this to the devel mailing list. Thanks for drawing it to my
attention.

Gavin

Re[3]: [Hibernate-devel] DateType java.util.Date and timezone

[Gavin_King/Cirrus%<CI...@ci...>]

>Bottom line for Hibernate:

>1. we could do nothing, and leave it to the user and the jdbc driver

>2. we could get the timezone from the Date with getTimezoneOffset()
>and force the time portion of the Date to midnight in that timezone

>3. we could use setDate(int parameterIndex, java.sql.Date x, Calendar cal)
>but not all drivers have it (plus, we'd have to construct the Claendar
>from the getTimezoneOffset() since jave.util.Date won't give it up)?

>I'd vote for 2 or 1 in that order, but I'd love to hear what others
>think.

Which of those choices best obeys principle-of-least-astonishment? Also, if
we started messing with times inside the Date, might we clobber
normalization already done by the application?

I'm pretty happy if:

1. It works for the default timezone
2. applications that need multiple timezones can handle normalization
themselves

Am I way off base?

Re[2]: [Hibernate-devel] DateType java.util.Date and timezone

[Doug C. <de...@fl...>]

I think I opened a can of worms.

>>How can the jdbc driver extract the DATE portion of the 'milliseconds
>>since January 1, 1970 00:00:00 GMT' accurately if it doesn't know the
>>timezone? The jdbc driver could assume local time, or could assume
>>GMT, but neither of these is as satisfactory as pulling the timezone
>>from the original Date.

> So, what is the _correct_ way to translate a java.util.Date to a
> java.sql.Date. My apologies for ignorance of something I guess I really
> should know.....!

A comment in java.sql.Date says:

>  * To conform with the definition of SQL DATE, the millisecond values
>  * wrapped by a java.sql.Date instance must be 'normalized' by setting the 
>  * hours, minutes, seconds, and milliseconds to zero in the particular
>  * time zone with which the instance is associated.

and the JDBC 2.1 spec says:

> An application should create a Date object using a Calendar. The
> application is responsible for specifying the time as 00:00:00 on
> the desired date when using the Calendar since the JDBC API uses
> this convention. In addition when creating a Time value the
> application must specify a date of January 1, 1970 to the Calendar
> used to create the millisecond value for the Time as this is the
> convention specified for time.

The comments in the jdbc 3.0 (jdk 1.4) java.sql.Date are clearer!?:

> Constructs a Date object using the given milliseconds time value. If
> the given milliseconds value contains time information, the driver
> will set the time components to the time in the default time zone
> (the time zone of the Java virtual machine running the application)
> that corresponds to zero GMT.

But this is ambiguous: how does the driver "know" if the "given
milliseconds value contains time information?" If the user picks a
timezone for the date, and sets the time to midnight there as
described in the preceeding two comments, how can the driver
distinguish this from any other random time? I guess the driver can
set the minutes, seconds, and milliseconds to zero, (maybe?), but it
can't touch the hours. Actually, there are some time zones that are
not an integral number of hours from GMT! I think the jdbc date spec
is crap. <soapbox> If I wrote the spec I'd say that *all* dates and
*all* times are represented as if they were in GMT since dates and
times don't really have timezones -- timestamps *do* have timezones,
they should carry the GMT time and a separate timezone offset.
</soapbox>

Bottom line for Hibernate:

1. we could do nothing, and leave it to the user and the jdbc driver

2. we could get the timezone from the Date with getTimezoneOffset()
and force the time portion of the Date to midnight in that timezone

3. we could use setDate(int parameterIndex, java.sql.Date x, Calendar cal)
but not all drivers have it (plus, we'd have to construct the Claendar
from the getTimezoneOffset() since jave.util.Date won't give it up)?

I'd vote for 2 or 1 in that order, but I'd love to hear what others
think.

e

Re: [Hibernate-devel] DateType java.util.Date and timezone

[Gavin_King/Cirrus%<CI...@ci...>]

> In cirrus.hibernate.type.DateType the set method does:
>  st.setDate(index, new Date( ( (java.util.Date) value).getTime() ) );

>This will discard any Calendar associated with the Date, and
>consequently any timezone associated with the Date.

aaaaahhhh. Thank you! I had a suspicion there was something screwy going on
with dates, but I couldn't figure it out (clueless about i18n issues) and
no-one had reported problems.....

>How can the jdbc driver extract the DATE portion of the 'milliseconds
>since January 1, 1970 00:00:00 GMT' accurately if it doesn't know the
>timezone? The jdbc driver could assume local time, or could assume
>GMT, but neither of these is as satisfactory as pulling the timezone
>from the original Date.

So, what is the _correct_ way to translate a java.util.Date to a
java.sql.Date. My apologies for ignorance of something I guess I really
should know.....!

I also just noticed that I overrode Type.equals(x, y) on DateType but not
on TimeType or TimeStampType. Clearly I also need to reimplement
equals(x,y) on TimeType. But is it also unsafe to use
timestamp1.equals(timestamp2) considering the timezone issues you raise?

[Hibernate-devel] DateType java.util.Date and timezone

[Doug C. <de...@fl...>]

In cirrus.hibernate.type.DateType the set method does:
  st.setDate(index, new Date( ( (java.util.Date) value).getTime() ) );

This will discard any Calendar associated with the Date, and
consequently any timezone associated with the Date.

How can the jdbc driver extract the DATE portion of the 'milliseconds
since January 1, 1970 00:00:00 GMT' accurately if it doesn't know the
timezone? The jdbc driver could assume local time, or could assume
GMT, but neither of these is as satisfactory as pulling the timezone
from the original Date.

e

Re: [Hibernate-devel] McKoi

[Gavin_King/Cirrus%<CI...@ci...>]

>I would feel more comfortable waiting until Toby releases 0.93. He has
>been supportive of my distributing the patches and descriptions of the
>shortcomings to the hibernate-devel list, but I think we should wait
>until a released Mckoi is more compatible right out of the box.

Fine, np. It looks like a pretty active project so I'm very keen to support
it.

>A counter-argument is that Mckoi seems to work almost as well as
>Interbase, so if you want to make the supported db list longer... :-).

I *have* had some doubts about whether Interbase belongs there. Given the
existing bugs, I personally would not use IB to develop a Java application
(the others on the list I would happily use, depending upon the situation).
However, I figure that if people are using IB, they must surely be well
aware of the bugs and living with them. So theres no reason for them to not
use Hibernate.....

Re: [Hibernate-devel] McKoi

[Doug C. <de...@fl...>]

> Many thanks for all this great stuff. If you think Hibernate + McKoi are
> working well together now then we should document the fact - add McKoi to
> the supported list, along with a list of the problems and a pointer to your
> patch. (I was kind of aware that there were issues with McKoi, so I had
> never mentioned it in the documentation so far.)

I would feel more comfortable waiting until Toby releases 0.93. He has
been supportive of my distributing the patches and descriptions of the
shortcomings to the hibernate-devel list, but I think we should wait
until a released Mckoi is more compatible right out of the box.

A counter-argument is that Mckoi seems to work almost as well as
Interbase, so if you want to make the supported db list longer... :-).

>> I have determined that Mckoi supports composite keys just fine; the
>> problem was in the handling of Dates as keys.
> (snip)
>> It seems that Mckoi stores all the milliseconds in the database

> So are DATE and TIMESTAMP synonyms in McKoi? Strange.

Yeah. Mckoi just puts the long value date.getTime() into the database
for all three types DATE TIME and TIMESTAMP (actually I think
TIMESTAMP maybe gets a few more bits). Toby has fixing this on his TO
DO list.

e

[Hibernate-devel] GUI for MappingByReflection

[Doug C. <de...@fl...>]

I have placed a partially implemented GUI for MappingByReflection into
the cvs with hopes that it will inspire someone to take it over. I
figure if somebody sees the potential they might be motivated to show
me how to do it right!

Currently the class MapReflectGUI will let you add classes to the map,
and show you the evolving class hierarchy and properties in a
tree-table.

Some changes will be required by the MappingByReflection code before
we can do much more. Currently, for example, the table and column
names are generated on the fly when the final XML is printed. I plan
to create a separate pass over the roots of the map to generate the
table and column names so they can be edited before they are dumped. A
similar problem is that properties that refer to classes cannot be
classified as component, many-to-one, or serializable until all
classes have been added. So, we need a "no more classes" command that
will do the pass to generate db names and classify the properties.

I plan to add these capabilites to MappingByReflection soon, so if you
want to work on the GUI, please jump right in!

e

[Hibernate-devel] schemas

[Gavin_King/Cirrus%<CI...@ci...>]

As requested, I have implemented support for access to data in multiple
schemas. You may now specify an optional schema attribute everywhere the
table attribute may appear and/or on the <hibernate-mapping> tag.

I've tested this works for all "supported" databases except:

McKoi
HypersonicSQL
Postgres

Postgres certainly _doesn't_ work - it seems to need quoted identifiers
(ie. "owner.table" not owner.table). I will get on to this at some stage.

Re: [Hibernate-devel] Problem with testCompositeIDCollections in Postgresql 7.2

[Gavin_King/Cirrus%<CI...@ci...>]

Interesting. I'm certainly not seeing this problem with 7.1.3 and the
released 7.2 driver. I can't test with postgres 7.2 right now because I
don't have a linux box handy and 7.2 isn't ported to cygwin yet.

By the look of your logs, you are using an older version of Hibernate ....
could you try it out with the current version in CVS?

also, you can see a lot more by setting the system property
hibernate.debug=2

thanks

Gavin

[Hibernate-devel] Problem with testCompositeIDCollections in Postgresql 7.2

[<gwe...@cl...>]

Hello,

All seems to work corretly except 'testCompositeIDCollections'.
If I comment the method, then I get 'logfile'.
If I uncomment it, then I get 'errfile'.
I did not try to debug postgresql...
I will try to debug hibernate...

Best Regards=21
Gwenn.

[Hibernate-devel] McKoi

[Gavin_King/Cirrus%<CI...@ci...>]

Many thanks for all this great stuff. If you think Hibernate + McKoi are
working well together now then we should document the fact - add McKoi to
the supported list, along with a list of the problems and a pointer to your
patch. (I was kind of aware that there were issues with McKoi, so I had
never mentioned it in the documentation so far.)

> I have determined that Mckoi supports composite keys just fine; the
> problem was in the handling of Dates as keys.
(snip)
> It seems that Mckoi stores all the milliseconds in the database

So are DATE and TIMESTAMP synonyms in McKoi? Strange.

> - Long values 15 digit precision -- fixed by my patch
> - null valued Longs return 0     -- fixed by my patch

Strangely enough, both these problems also exist in the Interbase JDBC
driver. Wanna fix it too, Doug? ;) jk

Re: [Hibernate-devel] Problem with McKoi

[Doug C. <de...@fl...>]

Yet another Mckoi update...

I have determined that Mckoi supports composite keys just fine; the
problem was in the handling of Dates as keys. The FooBar test code
constructs a composite key containing a Date property initialized from
the current time. A later attempt to retreive the object by key
constructs a new composite key with an updated time (different
milliseconds). It seems that Mckoi stores all the milliseconds in the
database, and compares against them, too. I worked around this in the
test by setting the milliseconds explicitly; now the composite key
tests are successful.

Mckoi 0.92 currently has the following problems:
- Can't cast NULL to VARBINARY   -- fixed by mckoi.com patch
- Long values 15 digit precision -- fixed by my patch
- null valued Longs return 0     -- fixed by my patch
- bug in parsing "(not (A=B))"   -- Toby says it will be fixed in 0.93
- bug in parsing BETWEEN in complex query -- reported to To...@mc...
- bug? when using Date as key
- no complex sub-selects, it seems

The cvs server has an updated FooBar.java to accommodate Mckoi. It
works around the BETWEEN bug, the NOT = bug, and the Date bug, and
assumes my patches or their equivalent are in place.

If you are using Mckoi and want my patch, let me know.

e

Re: [Hibernate-devel] Problem with McKoi

[Doug C. <de...@fl...>]

Here is a Mckoi update...

Mckoi 0.92 currently has the following problems:
- Can't cast NULL to VARBINARY   -- fixed by mckoi.com patch
- Long values 15 digit precision -- fixed by my patch
- null valued Longs return 0     -- fixed by my patch **new**
- no sub-selects, it seems
- bug in parsing "(not (A=B))" -- Toby says it will be fixed soon
- bug in parsing BETWEEN in complex query -- reported to To...@mc...
- can't get composite keys to work

The cvs server has a slightly updated FooBar.java to accommodate
Mckoi. It works around the BETWEEN bug.

If you are using Mckoi and want my patch, let me know.

e

Re: [Hibernate-devel] Problem with McKoi

[Doug C. <de...@fl...>]

> I'm in the process of testing some mods to Hibernate to allow it to use
> multiple schemas.  As HSQLDB does not support schemas I thought I'd try 
> and use McKoi.   However I'm getting the following exception.  Has the 
> McKoi dialect passed all the FooBarTests?

test/FooBar.java is updated on the cvs server.

I have managed to mangle FooBar enough so that Mckoi passes, but only
after patching Mckoi from http://mckoi.com/database/ver/patches/ and
with my own patches (which I have reported to To...@mc...).

Mckoi currently has the following problems:
- Can't cast NULL to VARBINARY -- fixed by mckoi.com patch
- Long values 15 digit precision -- fixed by my patch
- null valued Longs return 0   -- reported to To...@mc...
  (it's curious that the preceeding two are just like interbase)
- no sub-selects, it seems
- bug in parsing "(not (A=B))" -- reported to To...@mc...
- bug in parsing complex query -- reported to To...@mc...

If you are using Mckoi and want my patch, let me know.

e

Re: [Hibernate-devel] Java 1.4 and assert()

[Phillip B. <phi...@cl...>]

I know this isn't a democracy but I'd like to cast a vote for using JUnit.

Gavin commented "I've never quite figured out why you need a complicated 
framework for testing."  My answer to that is simply "unit testing". If 
you're taking the XP approach then you should be testing everything that 
could possibly break.  In general that equates to unit testing - i.e. 
one test class per project class, where the tests are written first, and 
functional testing i.e. FooBarTest.  In this situation JUnit is well 
worth it.

Just my $0.02

Phillip B.

[Hibernate-devel] Problem with McKoi

[Phillip B. <phi...@cl...>]

I'm in the process of testing some mods to Hibernate to allow it to use 
multiple schemas.  As HSQLDB does not support schemas I thought I'd try 
and use McKoi.   However I'm getting the following exception.  Has the 
McKoi dialect passed all the FooBarTests?  I do not think its my changes 
causing this because everything still runs ok under HSQLDB.

testCreateUpdate...
Created connection 
tojdbc:mckoi:local://c:/java/projects/hibernate/db/mctest/db.conf, 
Isolation Level: 8
Flushing: cirrus.hibernate.test.Foo 4be1cb31:ec0e76bc:00ec:0e77089e:0000 
LOADED
cirrus.hibernate.test.Foo: string changed
[1] select next from hibernate_unique_key
[2] update hibernate_unique_key set next = ?
Generated new collection ID 65536 for table foobytes
Flushing 1 insertions, 1 updates, 0 deletions to 1 objects and updating 
3 collections....
cirrus.hibernate.collections.ArrayHolder@6f0be8:null-->cirrus.hibernate.impl.CollectionPersister@6df3f6
cirrus.hibernate.collections.ArrayHolder@78f7db:null-->cirrus.hibernate.impl.CollectionPersister@2bc3f5
cirrus.hibernate.collections.ArrayHolder@61899b:null-->cirrus.hibernate.impl.CollectionPersister@4e3f41
[1] insert into foos ( foo, long_, integer_, float_, double_, bytes, 
date_, timestamp_, boolean_, bool_, null_, short_, zero_, int_, string_, 
byte_, yesno, blobb_, nullBlob, status_, bin_, first_name, surname, 
count_, name_, subcount, subname, foo_id, class ) values ( ?, ?, ?, ?, 
?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, 
'cirrus.hibernate.test.Foo' )
java.lang.reflect.InvocationTargetException: 
com.mckoi.database.jdbc.MSQLException: Can't cast NULL to VARBINARY
        at 
com.mckoi.database.jdbcserver.LocalDatabaseInterface.exec(LocalDatabaseInterface.java:194)
        at 
com.mckoi.database.jdbcserver.LocalDatabaseInterface.execQuery(LocalDatabaseInterface.java:229)
        at 
com.mckoi.database.jdbc.MConnection.executeQuery(MConnection.java:265)
        at 
com.mckoi.database.jdbc.MStatement.executeQuery(MStatement.java:110)
        at 
com.mckoi.database.jdbc.MPreparedStatement.executeUpdate(MPreparedStatement.java:76)

This is with McKoi 0.92.

thanks

Phillip B.

Re: [Hibernate-devel] Java 1.4 and assert()

[Paul S. <pau...@ne...>]

Gavin_King/Cirrus%CI...@ci... wrote:
> Thanks Gabe, I will change that methodname. As to using JUnit, I was just
> trying to keep hibernate as free of dependency upon other projects as
> possible. I'm happy to use JUnit if anyone can think of a compelling reason
> to use it but I've never quite figured out why you need a complicated
> framework for testing. (I have used JUnit in other projects.)

I can think of one reason at least: familiarity. There's more chance 
that someone will contribute to test cases if they're familiar with 
JUnit than having to learn yet-another-testing framework.

Case in point: a couple of bugs I found recently I started looking at 
how test cases are done, and decided I really didn't want to waste time 
learning what the testing framework was in Hibernate (no matter how 
simple it may be).

PaulS :(

Re: [Hibernate-devel] Java 1.4 and assert()

[Gavin_King/Cirrus%<CI...@ci...>]

Thanks Gabe, I will change that methodname. As to using JUnit, I was just
trying to keep hibernate as free of dependency upon other projects as
possible. I'm happy to use JUnit if anyone can think of a compelling reason
to use it but I've never quite figured out why you need a complicated
framework for testing. (I have used JUnit in other projects.)