From: Gavin_King/Cirrus%<CI...@ci...> - 2002-03-05 01:22:30
|
> I was wondering how difficult it would be to support database native > keys in hibernate (i.e. indentity columns in sybase/mssql), or if theres > a reason why its not implemented atm in hibernate. If its really easy i > could take a look at implementing it ;) It would be great if you could get this going. It would certainly be a great feature to have. I think the main difficulty would be this: 1. Hibernate always delays executing SQL statements until a flush(), so you can't know what the generated key is until _after_ you execute the insert. 2. Hibernate uses the key in its internal data structures (and in other ways) so its expecting to know the key _before_ you execute the insert. Fixing this *should* be as simple as deciding to execute the insert immediately for some classes (and sticking with the current behaviour for others). Have a look at: (1) RelationalDatabaseSession.save(Object object, Serializable id) (2) ClassPersister.insert(insert(Serializable id, Object[] fields, SessionImplementor session) These two methods do the work of (1) * assigning an id, * calling PersistentLifecycle.create(), * copying the state of the object, * nullifying references to transient objects (in the copied state), * registering the object and its copied state in the sessions internal data structure, * scheduling the actual insertion for later (2) * actually executing the SQL insert The class ScheduledInsertion adds an indirection between save() and insert () that lets Hibernate execute the insertion "later". I suppose you would want to remove this indirection.... Good Luck! |
From: Gavin_King/Cirrus%<CI...@ci...> - 2002-03-05 14:42:47
|
Cool! Sounds great. > * Added a public boolean isNative function to the IDGenerator interface. > All old generators return false here, the NativeGenerator returns true. I'm wondering if this is the best place for this flag. Can't see how its used but I would have been tempted to plonk it on ClassPersister instead. My reasoning is that there will only ever be that one single implementation of IDGenerator where it returns false. By adding the method to IDGenerator we force every future implementation of the interface to declare a method that does the exact same thing. There are three places where hibernate is supposed to support user-extension * cirrus.hibernate.sql.Dialect * cirrus.hibernate.id.IDGenerator * cirrus.hibernate.type.Type People have gone crazy adding new Dialects which is All Good. I had hoped for a bit more action in the other areas..... Now, Type has already got a little bit out of hand and will probably be slightly refactored sometime soon (before 1.0). I notice no-one has taken the plunge and tried to add new Types so far. This is probably an indication that something is wrong. (Or maybe everyone is just so happy with the existing Types.) Doesn't someone out there need BLOB support?? This can't be part of the "official" API because some priority target platforms (Postgres) don't have BLOBS yet. Still, I would happily distribute BLOBType with the rest of the project.... I think what I just did is called "going off on a tangent". Anyways my point was lets try and keep IDGenerator and Dialect as trivial as possible. If possible. Cool? |
From: Christoph S. <ch...@sc...> - 2002-03-05 15:05:33
|
Hi Gavin! thanks for your feedback! Gavin_King/Cirrus%CI...@ci... wrote: >Cool! Sounds great. > >>* Added a public boolean isNative function to the IDGenerator interface. >>All old generators return false here, the NativeGenerator returns true. >> > >I'm wondering if this is the best place for this flag. Can't see how its >used but I would have been tempted to plonk it on ClassPersister instead. >My reasoning is that there will only ever be that one single implementation >of IDGenerator where it returns false. By adding the method to IDGenerator >we force every future implementation of the interface to declare a method >that does the exact same thing. > There needs to be a way to tell hibernate to use the native key generator for a table. And the code needs to check for it. Do you think its better to compare the class of the keygenerator? >Doesn't someone out there need BLOB support?? This can't be part of the >"official" API because some priority target platforms (Postgres) don't >have BLOBS yet. Still, I would happily distribute BLOBType with the rest >of the project.... > What? no blobs? :P how does postgres handle binary data then? > > >I think what I just did is called "going off on a tangent". > >Anyways my point was lets try and keep IDGenerator and Dialect as trivial >as possible. If possible. Cool? > I will have to add two things to Dialect: one for the identity select, and one for the creation of the identity column. Tell me what you think, and I'll go ahead :) regards chris |
From: Gavin_King/Cirrus%<CI...@ci...> - 2002-03-05 15:24:26
|
> There needs to be a way to tell hibernate to use the native key > generator for a table. And the code needs to check for it. Do you think > its better to compare the class of the keygenerator? hhmmmmm instanceof sort of looks bad though in this case its perfectly defensible. My suggestion was to have ClassPersister.isUsingNativeKeyGeneration() or something. But then you would need to set that up in the first place which would involve doing either an instanceof or equivalent anyway.... How about if we use instanceof in the constructor of ClassPersister where its nice and hidden away and no-one will notice it ;) I'm not quite joking; I'd prefer "expedient" things in any class other than RelationalDatabaseSession. Yeah, I know I wouldn't be able to defend this if pressed .... whatever ..... just stick an instanceof wherever you think is right..... I'm rambling today.... > What? no blobs? :P > how does postgres handle binary data then? Very Badly. http://www.postgresql.org/idocs/index.php?lo-interfaces.html Actually there are large objects but theres some wierd way of using them I don't understand.... Also theres a varbinary type, of course. > I will have to add two things to Dialect: one for the identity select, > and one for the creation of the identity column. Thats all good. I'm not at all perturbed by that (anyway Dialect is an abstract class, not an interface, so we can do more with it). |
From: Christoph S. <ch...@sc...> - 2002-03-05 16:41:36
|
Gavin_King/Cirrus%CI...@ci... wrote: > >>There needs to be a way to tell hibernate to use the native key >>generator for a table. And the code needs to check for it. Do you think >>its better to compare the class of the keygenerator? >> > >hhmmmmm instanceof sort of looks bad though in this case its perfectly >defensible. My suggestion was to have > > ClassPersister.isUsingNativeKeyGeneration() > ok, i added a boolean to ClassPersister, and I init it with instanceof. I'll also document it in the native id generator. > > > >>I will have to add two things to Dialect: one for the identity select, >>and one for the creation of the identity column. >> > >Thats all good. I'm not at all perturbed by that (anyway Dialect is an >abstract class, not an interface, so we can do more with it). > One problem that i realized now is that the Classpersister is not aware of the DatabaseDialect. The Database Dialect is only set when a schema is generated. For the database native keys to work, it will be necessary that this Property is set. I'm quite happy with it being a property, because i want to use one mapping file for different databases. One more thing: How can I run the unit tests? Is this documented somewhere? regards chris > > > >_______________________________________________ >Hibernate-devel mailing list >Hib...@li... >https://lists.sourceforge.net/lists/listinfo/hibernate-devel > > |
From: Gavin_King/Cirrus%<CI...@ci...> - 2002-03-05 16:57:39
|
> One problem that i realized now is that the Classpersister is not aware > of the DatabaseDialect. The Database Dialect is only set when a schema > is generated. For the database native keys to work, it will be necessary > that this Property is set. I'm quite happy with it being a property, > because i want to use one mapping file for different databases. A recent change made the SessionFactory know the dialect. If necessary, pass it in to RelationalDatabaseSession. The 0.9.8 will be the first version where hibernate will issue platform-dependent SQL at runtime. Thats okay, it had to happen eventually.... > One more thing: How can I run the unit tests? Is this documented somewhere? Not documented. Guess it should be. Its easy enough, just run FooBarTest from the main method, passing in the name of the database as an argument. It will need to be able to find connection.properties and you will need to edit connection.properties with the correct values for you db. |
From: Brad C. <bra...@wo...> - 2002-03-06 01:02:58
|
it would make sense for the creation of the test case schema(s) and the running of the test cases to be ant tasks. if i get time, i will look at this sometime in the next week or so. brad ----- Original Message ----- From: <Gavin_King/Cirrus%CI...@ci...> To: "Christoph Sturm" <ch...@sc...> Cc: <hib...@li...> Sent: Wednesday, March 06, 2002 2:46 AM Subject: Re: [Hibernate-devel] database native keys > > > One problem that i realized now is that the Classpersister is not aware > > of the DatabaseDialect. The Database Dialect is only set when a schema > > is generated. For the database native keys to work, it will be necessary > > that this Property is set. I'm quite happy with it being a property, > > because i want to use one mapping file for different databases. > > A recent change made the SessionFactory know the dialect. If necessary, > pass it in to RelationalDatabaseSession. The 0.9.8 will be the first > version where hibernate will issue platform-dependent SQL at runtime. > Thats okay, it had to happen eventually.... > > > One more thing: How can I run the unit tests? Is this documented > somewhere? > > Not documented. Guess it should be. Its easy enough, just run FooBarTest > from the main method, passing in the name of the database as an argument. > It will need to be able to find connection.properties and you will need > to edit connection.properties with the correct values for you db. > > > _______________________________________________ > Hibernate-devel mailing list > Hib...@li... > https://lists.sourceforge.net/lists/listinfo/hibernate-devel > |
From: Christoph S. <ch...@sc...> - 2002-03-07 01:10:02
|
Gavin_King/Cirrus%CI...@ci... wrote: >Ah! duh, of course, didn't realise ..... you are using native key >generation >for a toplevel collection! Hadn't even occured to me. > >CollectionPersister.updateID() does the key generation for collections if >you want to have a look. > >Is it even possible to use native key generation for collections?? > >They don't have primary keys.... I mean, there are multiple rows, with the >same key. I've no idea how this would work. (I've never ever used native >key >generation myself, so excuse my ignorance.) > > > ok, then its not possible. I will add a check that the native idgenerator is not used for a collection. |
From: Gavin_King/Cirrus%<CI...@ci...> - 2002-03-07 01:14:45
|
> ok, then its not possible. I will add a check that the native > idgenerator is not used for a collection. yep, cool. I don't think the lack of native key generation for toplevel collections is a big deal. I don't think other O/R mapping tools even _have_ such a concept as toplevel collections.... (We really have them mainly because we have subcollections.) |
From: Christoph S. <ch...@sc...> - 2002-03-07 17:27:11
|
Ok, I have now checked in the database native keygeneration. It should work for MySQL and mssql/sybase. To use it just use <generator class="native"/> I hope all works ok. regards chris Gavin_King/Cirrus%CI...@ci... wrote: >>ok, then its not possible. I will add a check that the native >>idgenerator is not used for a collection. >> > >yep, cool. > >I don't think the lack of native key generation for toplevel >collections is a big deal. I don't think other O/R mapping >tools even _have_ such a concept as toplevel collections.... > >(We really have them mainly because we have subcollections.) > > >_______________________________________________ >Hibernate-devel mailing list >Hib...@li... >https://lists.sourceforge.net/lists/listinfo/hibernate-devel > > |
From: Gavin_King/Cirrus%<CI...@ci...> - 2002-03-07 20:34:14
|
That all looks really good, chris. (There was one tiny problem where the insert string was wrong for a table with no other columns but thats a far-from-typical case.) 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? |
From: Christoph S. <ch...@sc...> - 2002-03-08 01:26:32
|
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 |
From: Gavin_King/Cirrus%<CI...@ci...> - 2002-03-08 01:35:59
|
> 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. |
From: Gavin_King/Cirrus%<CI...@ci...> - 2002-03-08 02:59:29
|
(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. |
From: Doug C. <de...@fl...> - 2002-03-08 04:57:26
|
> (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 |
From: Phillip B. <phi...@cl...> - 2002-03-08 20:54:39
|
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 |
From: Christoph S. <ch...@sc...> - 2002-03-05 14:05:48
|
Hi Gavin! Thanks for the pointers. I implemented native key generation now for mssql server in a quite raw fashion, and I can send you the patches after some more tests. What I did: * Created A new key generator (NativeGenerator), and put it into the idgenerators map. This generator returns null as id. * Added a public boolean isNative function to the IDGenerator interface. All old generators return false here, the NativeGenerator returns true. * removed the id column from the insert if the idgen is native. * RelationalDatabaseSession.save(Object object, Serializable id) now calls the insert instead of creating a ScheduledInsert, but only if id == null * ClassPersister.insert(insert(Serializable id, Object[] fields,SessionImplementor session) now returns the generated id as Serializable. Whats still left to do is get the identity select from the DatabaseDialect, and modify the schema generation to generate identity columns. regards chris Gavin_King/Cirrus%CI...@ci... wrote: >>I was wondering how difficult it would be to support database native >>keys in hibernate (i.e. indentity columns in sybase/mssql), or if theres >>a reason why its not implemented atm in hibernate. If its really easy i >>could take a look at implementing it ;) >> > >It would be great if you could get this going. It would certainly be a >great feature to have. I think the main difficulty would be this: > >1. Hibernate always delays executing SQL statements until a flush(), so you >can't know what the generated key is until _after_ you execute the insert. >2. Hibernate uses the key in its internal data structures (and in other >ways) so its expecting to know the key _before_ you execute the insert. > >Fixing this *should* be as simple as deciding to execute the insert >immediately for some classes (and sticking with the current behaviour for >others). > >Have a look at: > >(1) RelationalDatabaseSession.save(Object object, Serializable id) >(2) ClassPersister.insert(insert(Serializable id, Object[] fields, >SessionImplementor session) > >These two methods do the work of >(1) > * assigning an id, > * calling PersistentLifecycle.create(), > * copying the state of the object, > * nullifying references to transient objects (in the copied state), > * registering the object and its copied state in the sessions internal >data structure, > * scheduling the actual insertion for later > >(2) > * actually executing the SQL insert > >The class ScheduledInsertion adds an indirection between save() and insert >() that lets Hibernate execute the insertion "later". I suppose you would >want to remove this indirection.... > >Good Luck! > > > |