Re: [Springframework-developer] Petclinic Hibernate implementation

[Colin S. <col...@ex...>]

Interesting, so in the case of sequences (Oracle sequences, in any 
case), Hibernate's save (or saveOrUpdate) will go and read the next 
sequence value from the db, so it can assign the id, but will not 
actually write the row until the flush. In the case of identity columns, 
it does an actual write immediately (as per your comment below), which 
makes sense, as it's the only way it can actually get the id value to 
assign to the objects as part of the save or saveOrUpdate.

This all has interesting implications in a few respects, including 
performance. Basically, I think user or Hibernate assigned IDs (such as 
GUIDs) would perform best, since the db is not hit until the actual 
entity write, followed by a seqhilo (hilo which uses a sequence for one 
half the value), followed by a hilo, then sequences, then identity.



jürgen höller [werk3AT] wrote:

>Colin, Trevor,
> 
>Session.save immediately inserts the object to the database, therefore it is able to set id into the object in any case. AFAIK, Session.update just inserts the object into the Session's object cache, to be flushed in the normal way. So Session.save seems to receive special treatment.
> 
>  
>
>>>auto-increment just allows to read in the actual id afterwards
>>>      
>>>
>>This is not reliable for concurrent inserts (which is why I generally use sequences.  For the sample this should be sufficient though.
>>    
>>
> 
>This is not reliable even with proper transactions? Shouldn't "last_insert_id" or whatever it is called return the last inserted id in the same transaction, allowing for concurrent inserts in different transactions?
> 
>Basically, the change for the sample would be straightforward: Drop all the manually handled sequence tables and turn the id columns into identity columns. This would allow for using Hibernate's out-of-the-box "identity" strategy; the JDBC implementation would have to do manual "last_insert_id" queries after the actual domain inserts.
> 
>Juergen
> 
>
>	-----Ursprüngliche Nachricht----- 
>	Von: Colin Sampaleanu [mailto:col...@ex...] 
>	Gesendet: Mo 20.10.2003 05:27 
>	An: spr...@li... 
>	Cc: 
>	Betreff: Re: [Springframework-developer] Petclinic Hibernate implementation
>	
>	
>
>	jürgen höller [werk3AT] wrote:
>	
>	>Hi everybody,
>	>
>	>...
>	>
>	>BTW, we are using auto-increment for all MySQL databases at werk3AT, and it works nicely. I'd really like to understand the rationale for manual sequence handling. The only one I see is that the id can be determined before the domain insert/update statement this way, while auto-increment just allows to read in the actual id afterwards. But does that really matter for Petclinic? Wouldn't it be easier to use auto-increment/identity on both MySQL and HSQL?
>	>
>	> 
>	>
>	Only somewhat related, but how does the auto-increment get handled
>	w/regards to Hibernate's 'save' function? That is, with an Oracle
>	sequence or some of the other (hi/lo, etc.) strategies, when you call
>	Hibernate's save function, your objects will get proper ids, even though
>	they don't get written to the db until they actually get flushed. This
>	is because the db has already been hit for the Oracle sequence or for
>	the manual sequence table column.
>	
>	What happens in your case with MySQL's auto-increment columns
>	(essentially similar to SQL Server's identity columns). Do the IDs stay
>	null (or whatever the unsaved value is) until Hibernate's flush actually
>	gets called?
>	 Just curious since I've never used either MySQL or SQL Server with
>	Hibernate...
>	
>	Colin
>	
>	
>