A few weeks ago I posted on the Forum and Gavin responded, but I'd like to know if anyone has taken a look at my response. Is there another purpose that I'm not seeing for Session.replicate() ? It reads that in the case of an IDENTITY table the replicate does not honour its documented contract but does a Session.save() instead.
Would it be possible to throw an exception (that does not disrupt session state) in the case where replication would not be possible. Or if all exceptions disrupt session state, provide a means where the the caller can see if a replicate is possible with a given object, to allow programatic checking.
Then provide a Session.replicateOrSave() API call for those users who really want the existing behaviour. This change needs to be made clear to allow users to modify their code but in the short term no damage would be done as every call to replicate() will result in an exception that they will investigate to fix and then they will learn of the change.
At least this leaves the door open in the future as SQL server technology improves across the board for enabling this feature progressivly and you dont have to work out the exact mechanism for enablement right now just have a simple flag per class mapping which by default is disabled.
It would be bad of hibernate to tie itself to the lowest common demoninator, the feature exists in some SQL servers becauses it incredibly useful.
http://forum.hibernate.org/viewtopic.php?t=949574&highlight= Your thoughts? -- Darryl L. Miles ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
