Not sure if anyone replied to this yet or not, so I'll throw my $0.02
into the discussion.  I think all that is needed is to better allow
definition of what is to occur during replication in the method call.
For example, consider the changing the signature from accepting a
ReplicationMode to accepting a (new) "ReplicationStrategy", where
ReplicationStrategy is defined something like:
ReplicationStrategy {
    /**
     * How should we react when we encounter a pre-existing row
     * in the target database?
     * <p/>
     * TODO: probably rename the ReplicationMode class to MergeMode
     */
    public ReplicationMode getMergeMode() ... 
    /**
     * When replicating an entity which does not yet occur in the
     * target database, should we enforce that the target data
     * we are about to create have the same identifier value?
     */
    public boolean forceIdentiferRetention() ...
}

Also, there has been some discussion about moving the replicate
functionality from the Session interface to the StatelessSession
interface which would be a good point in time to introduce such changes.

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Darryl Miles
Sent: Tuesday, August 01, 2006 12:47 PM
To: hibernate-devel@lists.sourceforge.net
Subject: [Hibernate] Session.replicate() into IDENTITY table ?


A while ago I highlighted a problem with the differences between the 
documented API and what Hibernate actually does and I'm seeking to an 
open discussion about the merits and problems to renaming the current 
#replicate() function to #replicateOrSave() to better identify what it 
actually does.

This is so that a hole can be left open to implement a real #replicate()

function which makes contact guarantees that the primary key / OID will 
be identical even in IDENTITY tables in the replicated object or 
otherwise it throws an exception.  There should also be a feature 
enquiry function to allow the API programmer to ask the underlying 
Hibernate implementation to verify if a replication on identity table 
will work.  This would account for JDBC driver vendors and versions and 
the realtime SQL database server vendor and version.

http://www.mail-archive.com/hibernate-devel@lists.sourceforge.net/msg052
30.html
http://forum.hibernate.org/viewtopic.php?t=949574&highlight=
http://www.hibernate.org/hib_docs/v3/api/org/hibernate/Session.html#repl
icate(java.lang.Object,%20org.hibernate.ReplicationMode)

RFC

Darryl


------------------------------------------------------------------------
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDE
V
_______________________________________________
hibernate-devel mailing list
hibernate-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hibernate-devel

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
hibernate-devel mailing list
hibernate-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hibernate-devel

Reply via email to