hibernate-devel — development

[Hibernate-devel] SAP DB dialect

[Brad C. <bra...@wo...>]

i have just commited the sap db dialect to cvs.

gavin, r u still happy for me to change the default column name for the
hilogenerator from next to next_hi (sap db gets upset when DBSchemaExport
tries to create the hibernate_unique_key table with a column name of next,
as it is a reserved word)?

the test suite fails on testCreateUpdate due to the size of the double in
Foo.java.  sap db seems to support to +1e-64, but Foo's double is set to
1.33e-69, so the exponent seems to large to me.  however the jdbc driver
appears to reduce it even more.  i could only get to 1.33e-36 for the test
to be successful.  i will send a message to the sapdb mailing list about
this.

brad

_______________________________
brad clow
chief technical officer
workingmouse

email: bra...@wo...
web:   http://www.workingmouse.com

Re: [Hibernate-devel] Re: share objects between different sessions

[Sven W. <s_...@in...>]

> >> (1) Does the "state" of the transient instance include it's id? Since
> >> hibernate allows the Session to track id's, I'm thinking, on the face
> >> of it, the answer is "no".
>
> > Hmm, this raises the question: How do I find the old record in the
> > database ? So, the answer is "yes" because ID is usually a property that
> is
> > stored inside the transient/persisted object.
>
> What I was really getting at here was: Do we use the id held _inside_ the
> object, or do we let the application provide it? Should it be:
>
>   persistentObject = Session.update(transientObject);
>
> or:
>
>   persistentObject = Session.update(id, transientObject);
>
> or should we allow both forms?
I don't know but if I have to choose I would only use the first one
because we're persisting objects to a database and everything in the
database has to be identifyable. "Normal" objects in c++/java/smalltalk
do not have an ID but tuples in a (relational) db must have one.


> >> (2) Does the "state" of the transient instance include it's version
> number?
> >> I'm thinking the answer is to this would be "yes".
>
> > Yes, a version number would really help. But we have to be aware that
> having
> > a single version number does _not_ guarantee serializability (there are
> > phantom reads and non repeatable reads). Ok, it is possible to set the
> > transaction isolation in the jdbc driver to serializable but then the
> question
> > appears why having version numbers at all.
>
> I'm assuming that the most typical use of this functionality would be to
> load a persistent object in one transaction (the first session) and then
> update it in a second (transaction and session). ie. It would be used with
> what we are calling "long transactions with versioning". Obviously if this
> is not the case and we are doing everything in one transaction, versioning
> is not such an important issue.
 *agreed*
> I'm not suggesting that we disable the functionality for non-versioned
> objects, merely asking wether we use the version number held by the
> transient instance, or the version number held by the existing persistent
> instance when we update. It seems clear that it should be the version
> in the transient instance.
For versioned objects using the transient instance makes sense.

> If I call
>
>   Session.update(transientObject);
>   Object persistentObject = Session.load( transientObject.getID() );
>
> Does transientObject == persistentObject ?
>
> I'm thinking *no*. Other persistent objects loaded by the session might
> already have references to the object with the given id and it would be
> a very difficult problem to swap all their references to point to
> transientInstance. Even then, the application might have pointers to
> persistentObject. Hence, I favor the form:
>
>   persistentObject = Session.update(transientObject);
>
> which returns another instance of the class, with the same id and
> persistent
> state as transientObject.
I do not see a problem with this approach.
  transientObject == persiententObject --> false
  transientObject.equals (persistentObject) --> true
But I do not know whether update is the right function name for such a
functionality with these semantics. I would not expect to get a new object
back after an db update.

Please let me add that update() has to be efficient in terms of DB access
because it will be called very often if stateless session beans are used.
This implies that we need some kind of hints a programmer may
provide.  e.g.
  Object update (Object instance, boolean deferredCheck) :
    do not reload the persistent instance from database but instead check
    versions at the end of the transaction on
    database update/delete: if updateCount == 0 --> rollback
  Object updateNonVersioned (Object instance, boolean isDirty) :
    ! the programmer has to do the concurrency checking !
	isDirty=true -> issue an db update
        isDirty=false -> just put it in the session
This might me useful if there are custom concurrency checking methods.

[Hibernate-devel] new ant test target

[Brad C. <bra...@wo...>]

i have added a new ant target "test" that executes the test suite.

to use it, u will need to set the property "test.database" in one of the
many ways supported - command line, your own build.properties in the
hibernate directory, or in a .ant.properties in your home directory.  it
defaults to db2, since that is what the connection.properties file is
defaulted to.

brad

_______________________________
brad clow
chief technical officer
workingmouse

email: bra...@wo...
web:   http://www.workingmouse.com

[Hibernate-devel] XML databinding.

[Gabe H. <gjh...@ya...>]

Why was JDom chosen as the XML toolkit of choice?  I
think using Dom4J or something else that supports
XPath would make life much easier in the mapping file.
 

I am currently working on an XML mapping system where
I work (specific use) and am wondering what your plans
are for XML.  Is it going to be the same interface as
your SQL databinding?

Gabe Hicks

__________________________________________________
Do You Yahoo!?
Yahoo! Sports - live college hoops coverage
http://sports.yahoo.com/

Re: [Hibernate-devel] Re: share objects between different sessions

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

>> (1) Does the "state" of the transient instance include it's id? Since
>> hibernate allows the Session to track id's, I'm thinking, on the face
>> of it, the answer is "no".

> Hmm, this raises the question: How do I find the old record in the
> database ? So, the answer is "yes" because ID is usually a property that
is
> stored inside the transient/persisted object.

What I was really getting at here was: Do we use the id held _inside_ the
object, or do we let the application provide it? Should it be:

  persistentObject = Session.update(transientObject);

or:

  persistentObject = Session.update(id, transientObject);

or should we allow both forms?

>> (2) Does the "state" of the transient instance include it's version
number?
>> I'm thinking the answer is to this would be "yes".

> Yes, a version number would really help. But we have to be aware that
having
> a single version number does _not_ guarantee serializability (there are
> phantom reads and non repeatable reads). Ok, it is possible to set the
> transaction isolation in the jdbc driver to serializable but then the
question
> appears why having version numbers at all.

I'm assuming that the most typical use of this functionality would be to
load a persistent object in one transaction (the first session) and then
update it in a second (transaction and session). ie. It would be used with
what we are calling "long transactions with versioning". Obviously if this
is not the case and we are doing everything in one transaction, versioning
is not such an important issue.

I'm not suggesting that we disable the functionality for non-versioned
objects, merely asking wether we use the version number held by the
transient instance, or the version number held by the existing persistent
instance when we update. It seems clear that it should be the version
in the transient instance.

>> (3) Should replacement replace the actual instance, or just copy its
state
>> into the current persistent instance? I'm thinking: always do a copy.

> Sorry, I don't see a difference between replace and copy (may be my
> english :) If you're thinking: the updated record in the database has the
> same id as before I'm with you.

If I call

  Session.update(transientObject);
  Object persistentObject = Session.load( transientObject.getID() );

Does transientObject == persistentObject ?

I'm thinking *no*. Other persistent objects loaded by the session might
already have references to the object with the given id and it would be
a very difficult problem to swap all their references to point to
transientInstance. Even then, the application might have pointers to
persistentObject. Hence, I favor the form:

  persistentObject = Session.update(transientObject);

which returns another instance of the class, with the same id and
persistent
state as transientObject.

> I think it should be possible to persist single objects and a set of
> single objects at once because:
>  * updating single objects is easy to implement

this would be the first thing to implement.

>  * writing a special collection class with special add/update/remove
>   operations is also easy to implement

It would be nice to have something like:

  Iterator persistentObjects = Session.update(iteratorOfTransients);

But this would be equally useful for other Session operations like

  save(), insert(), delete()

So, i'd rather think about this later on as a seperate feature.

> * persisting a collection of single objects is a very common operation
> I don't think that having the possibility to persist large and complex
> object graphs is really necessary for everyday usage but would be a
> "nice thing to have".

agreed.

>> (5) If the transient instance contains references to other transient
>> instances, we at least need to figure out if some of these are actually
>> references to existing persistent instances and resolve those
references.
>> This would only be possible if the transient instances hold their id.
>> So i guess my initial answer to (1) is wrong and we should only allow
>> replacements for classes which have identifier properties.

> Is it possible to have objects without an identifier ? Are there examples
> where this might be useful ? (for non read-only objects)

hmmmmm I can imagine it might be occasionally useful but hibernate can
not presently use objects without primary keys (the id is used internally
by the Session). Objects without identifiers can not be updated nor
take part in associations, so they are not usually useful.

However, what *is* possible is that the objects themselves do not hold
a copy of the identifier. If the persistent class contains no identifier
property, hibernate can still associate ids with instances *inside* the
session. This mechanism breaks down once we start trying to reuse the
instance in a different session (we won't know what it's id).

My apologies to everyone for slowness lately. I've been sick and also
distracted by some other things.

Re: [Hibernate-devel] SQL Server 2000 questions

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

The one I have been using is JSQL from:

http://www.j-netdirect.com/

This particular driver seems to work beautifully.

I have just verified that Weblogic jDriver also works (with one very minor
test failure).

FreeTDS certainly does *not* work. I _think_ someone reported that

http://www.inetsoftware.de/

also does *not* work. (Havn't tried this myself)

The latest version of Microsoft's driver doesn't pass all tests, but it
does pass *some*. It might be almost possible to get it working, but I'm
not particularly optimistic. (If you want to try, you _must_ use the
SelectMethod=cursor JDBC connection parameter.)

Good Luck

Gavin

[Hibernate-devel] SQL Server 2000 questions

[Donnie H. <do...@ha...>]

I noted in the Intro/Install docs that the beta JDBC driver from MS doesn't
work w/ Hibernate. Some questions about that:

- is that the beta 2 driver from Dec. 2001 (the most recent from what I can
tell)?
- what are the problems w/ the driver, and are they insurmountable?
- what specific 3rd-party drivers for SQL Server do work?

Hibernate looks terrifically useful, and I'd like to use it in my current
project. SQL Server 2000 is a constraint, so I don't want to spend too much
time tilting against the wind.

Many thanks,

Donnie Hale
do...@ha...

[Hibernate-devel] Re: share objects between different sessions

[Sven W. <s_...@in...>]

> > If you want to use hibernate with stateless session beans you have to
> make
> > sure that you do everything at once within the session bean because when
> > the object under (hibernate)session control leaves the (ejb)session bean
> > via serialization there is no way to get this object back into the
> database.
>
> Stated slightly differently: We would like to be able to replace the state
> of
> a persistent instance with the state of a transient instance.
Ok, this is what I meant.
> This raises (at least) the following issues:
>
> (1) Does the "state" of the transient instance include it's id? Since
> hibernate allows the Session to track id's, I'm thinking, on the face
> of it, the answer is "no".
Hmm, this raises the question: How do I find the old record in the
database ? So, the answer is "yes" because ID is usually a property that is
stored inside the transient/persisted object.

> (2) Does the "state" of the transient instance include it's version number?
> I'm thinking the answer is to this would be "yes".
Yes, a version number would really help. But we have to be aware that having
a single version number does _not_ guarantee serializability (there are
phantom reads and non repeatable reads). Ok, it is possible to set the
transaction isolation in the jdbc driver to serializable but then the question
appears why having version numbers at all.
Sometimes it is useful to allow non versioned objects because there might
be a different approach to concurrency control for existing systems
that is unknown to hibernate (e.g combination of different timestamp
columns).

> (3) Should replacement replace the actual instance, or just copy its state
> into the current persistent instance? I'm thinking: always do a copy.
Sorry, I don't see a difference between replace and copy (may be my
english :) If you're thinking: the updated record in the database has the
same id as before I'm with you.

> (4) (Most Difficult) Where should replacement *stop*? To be very consistent
> with the current semantics of hibernate, it should probably just copy state
> from one entity (+ collections + components), rather than walking the graph
> of associated entities. However, this makes collections of entities quite
> difficult to use. The application itself would have to decide when to add
> new collection elements and when to update existing ones. My thinking on
> this is we should provide single object replacement at present, and leave
> the more difficult problem for later when/if we really start to address the
> "persistence-by-reachability" problem.
I think it should be possible to persist single objects and a set of
single objects at once because:
 * updating single objects is easy to implement
 * writing a special collection class with special add/update/remove
   operations is also easy to implement
 * persisting a collection of single objects is a very common operation
I don't think that having the possibility to persist large and complex
object graphs is really necessary for everyday usage but would be a
"nice thing to have".

> (5) If the transient instance contains references to other transient
> instances, we at least need to figure out if some of these are actually
> references to existing persistent instances and resolve those references.
> This would only be possible if the transient instances hold their id.
> So i guess my initial answer to (1) is wrong and we should only allow
> replacements for classes which have identifier properties.
Is it possible to have objects without an identifier ? Are there examples
where this might be useful ? (for non read-only objects)

> Hibernate has a sophisticated mechanism for extracting the persistent state
> of an instance, so I'm not seeing a really strong need for the Moveable
> interface.
For simple objects this is true but if there are complex object graphs
the situation may be different. Currently I do not know enough about
the interna of hibernate to prove this as right or wrong.

> > but for "Movable" objects it should be possible to get the old state
> > without the need of a real session.
> > For some movable objects it might be useful to do not keep an additional
> > state because you know when these objects are dirty which saves bandwidth
> > and coding time.
>
> I don't see a really compelling argument that this is something hibernate
> should provide. Yes, it would save a query to fetch the clean state of the
> instance but on the other hand it is very model-intrusive and wastes
> bandwidth as you noted. It may also subtly influence the transaction
> isolation semantics.
You always trade database I/O for bandwidth but it is impossible to say
which solution is _the_ best because sometimes you don't have bandwidth
and sometimes the database I/O is critical. So, supporting both does not
hurt.
For the transaction isolation I don't see where it increases or decreases
isolation. If you want to compare the old vs. new version the old version
should always be the version that was loaded originally.

> > Non versioned writes should also be allowed: (e.g. this is
> > useful if you want to do cross database replication between different
> > application servers).
>
> Not quite sure what you are describing here.
If you do not use hibernate with a brand new database schema there might
be already some different fields/columns that are used for concurrency
control. You have to be compatible with these fields and do concurrency
checks inside your application code.

> To sum up, my suggested API would be:
>
> public interface Session {
>     ....
>     public Object update(Object replacement);
>     ....
> }
>
> we would pass in a transient instance with an id property and
> receive back the corresponding persistent instance, with its state
> already updated. Perhaps we could allow the variant:
>
>     public Object update(Serializable id, Object replacement)
>
> for objects without id properties.
>
> Any problems with this approach?
No. But I would like to see the following additional:

  // to save database I/O
  public Object update (Object replacement, Object replacementAfterLoad);

  // or how about this ?
  public Object update (Object replacement, boolean isDirty);

  // to save a set of simple objects
  public void update (SpecialHibernateMap objectsToUpdate);

bye
 Sven

Re: [Hibernate-devel] updating db schema

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

Hey Chris.

sorry was slow responding to this....

I think this would be a wonderful feature that would ease a lot of pain.
The following feature request refers to the same problem:

http://sourceforge.net/tracker/index.php?func=detail&aid=516650&group_id=40712&atid=428711

It doesn't, unfortunately, seem to be an extremely easy feature to
implement. I don't have a lot of ideas on a good approach.

Gavin

Re: [Hibernate-devel] share objects between different sessions

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

> If you want to use hibernate with stateless session beans you have to
make
> sure that you do everything at once within the session bean because when
> the object under (hibernate)session control leaves the (ejb)session bean
> via serialization there is no way to get this object back into the
database.

Stated slightly differently: We would like to be able to replace the state
of
a persistent instance with the state of a transient instance.

This raises (at least) the following issues:

(1) Does the "state" of the transient instance include it's id? Since
hibernate allows the Session to track id's, I'm thinking, on the face
of it, the answer is "no".

(2) Does the "state" of the transient instance include it's version number?
I'm thinking the answer is to this would be "yes".

(3) Should replacement replace the actual instance, or just copy its state
into the current persistent instance? I'm thinking: always do a copy.

(4) (Most Difficult) Where should replacement *stop*? To be very consistent
with the current semantics of hibernate, it should probably just copy state
from one entity (+ collections + components), rather than walking the graph
of associated entities. However, this makes collections of entities quite
difficult to use. The application itself would have to decide when to add
new collection elements and when to update existing ones. My thinking on
this is we should provide single object replacement at present, and leave
the more difficult problem for later when/if we really start to address the
"persistence-by-reachability" problem.

(5) If the transient instance contains references to other transient
instances, we at least need to figure out if some of these are actually
references to existing persistent instances and resolve those references.
This would only be possible if the transient instances hold their id.
So i guess my initial answer to (1) is wrong and we should only allow
replacements for classes which have identifier properties.

> There has to be a mechanism that would allow us to get an object in/out
of
> a session with enough additional information that another session could
> use the object as is would've be loaded normally.

All that would be needed is the object itself and its identifier. If the
object does not keep its identifier, i think we can just expect the
application to provide it. The recommended practice is for objects to
declare an identifier property, anyway.

> (warning: I only had a look at the sources for about an hour)
> Currently hibernate maintains the complete state of an object within a
> session.

Not quite. Hibernate maintains a copy of the _old_ state, so that changes
made in a persistent instance can be discovered when we flush. It can
easily retrieve that from the database at any time.

Hibernate has a sophisticated mechanism for extracting the persistent state
of an instance, so I'm not seeing a really strong need for the Moveable
interface.

> It is VERY useful to have the old values around because you often have to
> do comparisons old vs. new. This should also be implemented in hibernate

yes, it is.

> but for "Movable" objects it should be possible to get the old state
> without the need of a real session.
> For some movable objects it might be useful to do not keep an additional
> state because you know when these objects are dirty which saves bandwidth
> and coding time.

I don't see a really compelling argument that this is something hibernate
should provide. Yes, it would save a query to fetch the clean state of the
instance but on the other hand it is very model-intrusive and wastes
bandwidth as you noted. It may also subtly influence the transaction
isolation semantics.

> It should be possible to have everything versioned to archive transaction
> isolation.

This should be covered by existing versioning functionality.

> Non versioned writes should also be allowed: (e.g. this is
> useful if you want to do cross database replication between different
> application servers).

Not quite sure what you are describing here.

To sum up, my suggested API would be:

public interface Session {
    ....
    public Object update(Object replacement);
    ....
}

we would pass in a transient instance with an id property and
receive back the corresponding persistent instance, with its state
already updated. Perhaps we could allow the variant:

    public Object update(Serializable id, Object replacement)

for objects without id properties.

Any problems with this approach?

[Hibernate-devel] share objects between different sessions

[Sven W. <s_...@in...>]

<quote from=http://sourceforge.net/forum/forum.php?thread_id=652104&forum_id=128638>
We should continue this discussion in the devel list. Could you please
post a summary of the needed functionality and your suggested solution to
the devel list, so we can start a proper discussion there? There are a
couple of questions remaining in my head which I need to run past
everyone....
</quote>
The problem:
If you want to use hibernate with stateless session beans you have to make
sure that you do everything at once within the session bean because when
the object under (hibernate)session control leaves the (ejb)session bean
via serialization there is no way to get this object back into the database.
What we need:
There has to be a mechanism that would allow us to get an object in/out of
a session with enough additional information that another session could
use the object as is would've be loaded normally. This has to be also
possible for object graphs but there should be a possiblity to restrict
the object graph because if you load the whole graph you might have the
whole database in the graph.
The serialized objects + additional information should be minimal because
bandwidth is often a problem in distributed systems.
Some ideas for a solutions: (warning: I only had a look at the sources for
about an hour)
Currently hibernate maintains the complete state of an object within a
session.
One solution would be to put the additional state information
that is needed in the persisted object:
  interface MovableObject {
    public setState (Object o);
    public getState (Object o);
  }
Every object that needs to be passed around has to implement this
interface. Within a session there are some branches like this:
   if (o instanceof MovableObject) o.get/setState(....)
   else {
     // This object is not movable so do as we've done before
     ...
   }
For "normal" objects nothing changes and everything is managed and saved
in the session.

This is the approach I'm currently using:

  public MyClass implements java.io.Serializable,PersistentLifecycle,
			    java.lang.Cloneable {
    ...
    public void saveValues () {
      try {
        oldValues = (MyClass)this.clone();
      }
      catch (Exception ex) {}
    }

    public MyClass getSavedValues () {
      return oldValues;
    }

    public void load(Session session) throws java.sql.SQLException,HibernateException {
      saveValues ();
    }
  }
  Session:
  void reassign (Object new, Object old);
  e.g. session.reassign (o, o.getOldValues);
  void reassign (Object new, boolean isDirty);

It is VERY useful to have the old values around because you often have to
do comparisons old vs. new. This should also be implemented in hibernate
but for "Movable" objects it should be possible to get the old state
without the need of a real session.
For some movable objects it might be useful to do not keep an additional
state because you know when these objects are dirty which saves bandwidth
and coding time.
Transactions:
It should be possible to have everything versioned to archive transaction
isolation. Non versioned writes should also be allowed: (e.g. this is
useful if you want to do cross database replication between different
application servers).

bye
 Sven

[Hibernate-devel] updating db schema

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

Hi All!

A really great feature would be if Hibernate detected if a table already
exists, and what columns it has, and just executes some alter table
commands instead of dropping and recreating the table. Does Anyone have
an idea how this could be implemented easily? It would be great if I
could just deploy a new web-app with a new mapping, and the database
schema is changed automatically.

Regards
  Chris

[Hibernate-devel] updating db schema

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

Hi All!

A really great feature would be if Hibernate detected if a table already 
exists, and what columns it has, and just executes some alter table 
commands instead of dropping and recreating the table. Does Anyone have 
an idea how this could be implemented easily? It would be great if I 
could just deploy a new web-app with a new mapping, and the database 
schema is changed automatically.

Regards
 Chris

[Hibernate-devel] 0.9.8

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

Just released a new version. Go check it out!

Gavin

[Hibernate-devel] Sequence ID Generator

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

Hi everyone,

I've just added support for sequences as an id generation strategy for DB2,
Oracle and Postgres. Other databases may be supported in their Dialects.

Enjoy.

I also improved the IDGenerator framework, so that generators can create
whatever persistent resources they need (eg. the table needed by
HiLoGenerator, the sequence needed by SequenceGenerator). This is a big
improvement (that, by side-effect, removed an annoying restriction on
sharing a hilo generator between mapping files).

Re: [Hibernate-devel] database native keys

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

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

>What other dbs support this? Oracle and Interbase don't have identity
>columns and I think the same goes for Postgres. This leaves:
>
>HSQL _does_ have identity columns.
>
>McKoi and Progress I'm not sure about.
>

Progress does not support identity columns.

Phil

Re: Re[4]: [Hibernate-devel] database native keys

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

>> how can i replicate this, Doug?

>I was just running FooBarTest with Mckoi.

OK, I will try + get McKoi runnning. I can't replicate the problem on any
other db, and I don't think the recent changes to support native key
generation would affect _deletions_ at all. So I'm at a loss.

May or may not get a chance to look at this tomorrow...

Re[4]: [Hibernate-devel] database native keys

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

>>> The native key generation rearranges the insertion order of objects and was
>>> causing foreign key constraint violations. I have made a quick (easy) fix,
>>> though something more efficient might be better in future. (Nothing changed
>>> for non-native key generation.)

>> I'm not so sure...

> how can i replicate this, Doug?

I was just running FooBarTest with Mckoi.

e

Re: [Hibernate-devel] Doug, whats the latest on McKoi?

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

> I see they have released a 0.9.3 preview....

Yes, I grabbed the preview.

> does this mean hibernate will work without patching McKoi now?

Unfortunately I got stuck on the foreign key constraint violations;
both 0.92 and 0.93rc1 get the error I reported yesterday. I haven't
dug into that in detail yet (I was hoping it would be obvious to you
since you'be been in that area of the code lately).

e

[Hibernate-devel] Doug, whats the latest on McKoi?

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

I see they have released a 0.9.3 preview....

does this mean hibernate will work without patching McKoi now?

Re: Re[2]: [Hibernate-devel] database native keys

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

> Mckoi has a function UNIQUEKEY which generates a uniqueid, but it
> doesn't seem to fit the model employed by Hibernate...

>     SELECT UNIQUEKEY('Orders')

DB2 also has something like this. I think its easy enough to write an
IDGenerator to take advantage of this style of key generator (ditto
oracle sequences, etc). Its the Identity column style that needs special
support.

P.S. If anyone wants to write an IDGenerator for Oracle sequences or
whatever, it would be a very worthwhile feature,

>> The native key generation rearranges the insertion order of objects and
was
>> causing foreign key constraint violations. I have made a quick (easy)
fix,
>> though something more efficient might be better in future. (Nothing
changed
>> for non-native key generation.)

> I'm not so sure...

how can i replicate this, Doug?

Re[2]: [Hibernate-devel] database native keys

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

> (1)
> The native key generation rearranges the insertion order of objects and was
> causing foreign key constraint violations. I have made a quick (easy) fix,
> though something more efficient might be better in future. (Nothing changed
> for non-native key generation.)

I'm not so sure...

testLoad...
Opened session
Generated new collection ID 262150 for table foobytes
Generated new collection ID 262151 for table foobytes
Flushing 3 insertions, 3 updates, 0 deletions to 3 objects and updating 6 collections....
[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' )
[2] insert into quux ( foo, deleted, loaded, stored, created, childKey, stuff, qux_key ) values ( ?, ?, ?, ?, ?, ?, ?, ? )
[3] insert into foos ( baz, bar_string, bar_count, name, importantDates, the_time, 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.Bar' )
[4] update foos set 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 = ? where foo_id = ?
[5] update quux set foo = ?, deleted = ?, loaded = ?, stored = ?, created = ?, childKey = ?, stuff = ? where qux_key = ?
[6] update foos set baz = ?, bar_string = ?, bar_count = ?, name = ?, importantDates = ?, the_time = ?, 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 = ? where foo_id = ?
Inserting collection: foobytes#262150
[7] insert into foobytes ( id, i, byte ) values ( ?, ?, ? )
Inserting collection: foo_dates#40288286:ec7443c9:00ec:74461cef:0011
[8] insert into foo_dates ( foo_id, i, date_ ) values ( ?, ?, ? )
Inserting collection: foo_times#40288286:ec7443c9:00ec:74461cef:0011
[9] insert into foo_times ( foo_id, i, date_ ) values ( ?, ?, ? )
Inserting collection: foobytes#262151
[10] insert into foobytes ( id, i, byte ) values ( ?, ?, ? )
Inserting collection: foo_times#40288286:ec7443c9:00ec:74461cef:0010
[11] insert into foo_times ( foo_id, i, date_ ) values ( ?, ?, ? )
Inserting collection: foo_dates#40288286:ec7443c9:00ec:74461cef:0010
[12] insert into foo_dates ( foo_id, i, date_ ) values ( ?, ?, ? )
Running Session.finalize()
Opened session
[1] select qux_key, foo, deleted, loaded, stored, created, childKey, stuff from quux where qux_key = ?
[2] select foo_id, class, 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, the_time, baz, bar_string, bar_count, name, importantDates from foos where foo_id = ?
Loading collection: foobytes#262150
[3] select byte, i from foobytes where id = ? order by i
Loading collection: foo_times#40288286:ec7443c9:00ec:74461cef:0010
[4] select date_, i from foo_times where foo_id = ? order by i
Loading collection: foo_dates#40288286:ec7443c9:00ec:74461cef:0010
[5] select date_, i from foo_dates where foo_id = ? order by i
[6] select foo_id, class, 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, the_time, baz, bar_string, bar_count, name, importantDates from foos where foo_id = ?
Loading collection: foos#40288286:ec7443c9:00ec:74461cef:0011
[7] select foo_id from foos where abstract_id = ?
Loading collection: foobytes#262151
[8] select byte, i from foobytes where id = ? order by i
Loading collection: foo_times#40288286:ec7443c9:00ec:74461cef:0011
[9] select date_, i from foo_times where foo_id = ? order by i
Loading collection: foo_dates#40288286:ec7443c9:00ec:74461cef:0011
[10] select date_, i from foo_dates where foo_id = ? order by i
[11] select foo_id, class, baz, bar_string, bar_count, name, importantDates, the_time, 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 from foos where foo_id = ?
[12] 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' )
Loading collection: Fum#327680
[13] select string_, short_, date_, posn from Fum where qux_id = ? order by posn
Loading collection: fums#327680
[14] select fum_string, fum_short, fum_date from fums where qux_id = ?
Flushing 0 insertions, 1 updates, 3 deletions to 3 objects and updating 9 collections....
[15] update quux set foo = ?, deleted = ?, loaded = ?, stored = ?, created = ?, childKey = ?, stuff = ? where qux_key = ?
Deleting collection: foo_times#40288286:ec7443c9:00ec:74461cef:0010
[16] delete from foo_times where foo_id = ?
Deleting collection: Fum#327680
[17] update Fum set qux_id = null where qux_id = ?
Deleting collection: foobytes#262151
[18] delete from foobytes where id = ?
Deleting collection: foo_dates#40288286:ec7443c9:00ec:74461cef:0010
[19] delete from foo_dates where foo_id = ?
Deleting collection: foo_dates#40288286:ec7443c9:00ec:74461cef:0011
[20] delete from foo_dates where foo_id = ?
Deleting collection: foobytes#262150
[21] delete from foobytes where id = ?
Deleting collection: foo_times#40288286:ec7443c9:00ec:74461cef:0011
[22] delete from foo_times where foo_id = ?
Deleting collection: foos#40288286:ec7443c9:00ec:74461cef:0011
[23] update foos set abstract_id = null where abstract_id = ?
Deleting collection: fums#327680
[24] delete from fums where qux_id = ?
[25] delete from foos where foo_id = ?
[26] delete from quux where qux_key = ?
[27] delete from foos where foo_id = ?
java.lang.reflect.InvocationTargetException
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:324)
        at cirrus.hibernate.test.TestCase.run(TestCase.java:46)
        at cirrus.hibernate.test.FooBarTest.main(FooBarTest.java:1216)
Caused by: com.mckoi.database.jdbc.MSQLException: Deferred foreign key constraint violation on delete (foo_datesFK0) Columns = APP.foo_dates( foo_id ) -> APP.foos( foo_id )
        at com.mckoi.database.jdbcserver.LocalDatabaseInterface.exec(Unknown Source)
        at com.mckoi.database.jdbcserver.LocalDatabaseInterface.execQuery(Unknown Source)
        at com.mckoi.database.jdbc.MConnection.executeQuery(Unknown Source)
        at com.mckoi.database.jdbc.MStatement.executeQuery(Unknown Source)
        at com.mckoi.database.jdbc.MStatement.executeQuery(Unknown Source)
        at com.mckoi.database.jdbc.MConnection.commit(Unknown Source)
        at cirrus.hibernate.impl.RelationalDatabaseSession.close(RelationalDatabaseSession.java:1903)
        at cirrus.hibernate.impl.RelationalDatabaseSession.commit(RelationalDatabaseSession.java:1867)
        at cirrus.hibernate.test.FooBarTest.testLoad(FooBarTest.java:185)
        ... 6 more

> (2)
> I also added support for DB2 native key generation. So the list so far is:

> MySQL
> Sybase
> MS SQL
> DB2

> What other dbs support this? Oracle and Interbase don't have identity
> columns and I think the same goes for Postgres. This leaves:

> HSQL _does_ have identity columns.

> McKoi and Progress I'm not sure about.

Mckoi has a function UNIQUEKEY which generates a uniqueid, but it
doesn't seem to fit the model employed by Hibernate...

     SELECT UNIQUEKEY('Orders')

     INSERT INTO Orders
        ( id, number, division, date_made, quantity,
          value )
       VALUES
        ( UNIQUEKEY('Orders'), CONCAT('Order-', id),
          'Bio Engineering', DATEOB(), 25, 1900.00 )


e

Re: [Hibernate-devel] database native keys

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

(1)
The native key generation rearranges the insertion order of objects and was
causing foreign key constraint violations. I have made a quick (easy) fix,
though something more efficient might be better in future. (Nothing changed
for non-native key generation.)

(2)
I also added support for DB2 native key generation. So the list so far is:

MySQL
Sybase
MS SQL
DB2

What other dbs support this? Oracle and Interbase don't have identity
columns and I think the same goes for Postgres. This leaves:

HSQL _does_ have identity columns.

McKoi and Progress I'm not sure about.

Re: [Hibernate-devel] database native keys

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

> I think thats database dependent, mysql will sometimes reuse id values,
> mssql and sybase dont.

Yeah, I checked up on DB2 and *it* doesn't. Its not such a problem if
ids are reused, but there is a possibility of hibernate throwing an
exception.

Re: [Hibernate-devel] database native keys

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

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

>I have a question:
>
>If, in a single transaction, I delete a row of a table and then insert a
>new row, is it likely that the inserted row would get the same generated id
>as the deleted row?
>
I think thats database dependent, mysql will sometimes reuse id values, 
 mssql and sybase dont.

regards
 chris