hibernate-devel

Re: [Hibernate] Session.replicate() into IDENTITY table ?

[Steve E. <ste...@jb...>]

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() ...=20
    /**
     * 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: hib...@li...
[mailto:hib...@li...] On Behalf Of
Darryl Miles
Sent: Tuesday, August 01, 2006 12:47 PM
To: hib...@li...
Subject: [Hibernate] Session.replicate() into IDENTITY table ?


A while ago I highlighted a problem with the differences between the=20
documented API and what Hibernate actually does and I'm seeking to an=20
open discussion about the merits and problems to renaming the current=20
#replicate() function to #replicateOrSave() to better identify what it=20
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=20
be identical even in IDENTITY tables in the replicated object or=20
otherwise it throws an exception.  There should also be a feature=20
enquiry function to allow the API programmer to ask the underlying=20
Hibernate implementation to verify if a replication on identity table=20
will work.  This would account for JDBC driver vendors and versions and=20
the realtime SQL database server vendor and version.

http://www.mail-archive.com/hib...@li.../msg052
30.html
http://forum.hibernate.org/viewtopic.php?t=3D949574&highlight=3D
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=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDE
V
_______________________________________________
hibernate-devel mailing list
hib...@li...
https://lists.sourceforge.net/lists/listinfo/hibernate-devel

Re: [Hibernate] Session.replicate() into IDENTITY table ?

[Steve E. <ste...@jb...>]

StatelessSession has nothing to do with lack of a transaction!


-----Original Message-----
From: Darryl Miles [mailto:dar...@ne...]=20
Sent: Friday, August 11, 2006 3:13 AM
To: Steve Ebersole
Cc: hib...@li...
Subject: Re: [Hibernate] Session.replicate() into IDENTITY table ?

Steve Ebersole wrote:
> 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() ...=20
>     /**
>      * 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() ...
> }
>=20
> 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.

The use of a strategy configuration object would fine from the Hibernate

API users perspective and head off the possibility of legacy API kruft=20
issues (when another parameter is wanted in the future).


Would I be correct in saying that operations using a StatelessSession=20
are not part of a transaction ?  If so are you proposing to _REMOVE_ the

Session#replicate() operation completely that is part of a transaction.=20
  Providing for both stateful and stateless would cover all bases and=20
have their valid use cases.  Maybe I am misunderstanding something here.

Darryl

Re: [Hibernate] Session.replicate() into IDENTITY table ?

[Steve E. <ste...@jb...>]

StatelessSession has nothing to do with lack of a transaction!

- meaning StatelessSession operates in a transaction exactly as does
Session...

-----Original Message-----
From: Darryl Miles [mailto:dar...@ne...]=20
Sent: Friday, August 11, 2006 3:13 AM
To: Steve Ebersole
Cc: hib...@li...
Subject: Re: [Hibernate] Session.replicate() into IDENTITY table ?

Steve Ebersole wrote:
> 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() ...=20
>     /**
>      * 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() ...
> }
>=20
> 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.

The use of a strategy configuration object would fine from the Hibernate

API users perspective and head off the possibility of legacy API kruft=20
issues (when another parameter is wanted in the future).


Would I be correct in saying that operations using a StatelessSession=20
are not part of a transaction ?  If so are you proposing to _REMOVE_ the

Session#replicate() operation completely that is part of a transaction.=20
  Providing for both stateful and stateless would cover all bases and=20
have their valid use cases.  Maybe I am misunderstanding something here.

Darryl

Re: [Hibernate] Session.replicate() into IDENTITY table ?

[Darryl M. <dar...@ne...>]

Steve Ebersole wrote:
> StatelessSession has nothing to do with lack of a transaction!
> 
> - meaning StatelessSession operates in a transaction exactly as does
> Session...

Ok I must have misunderstood its purpose (it being the 
StatelessSession), with its use for bulk operations that have no 
transaction or coherency requirements outside of the currently executing 
instruction.

Darryl

Re: [Hibernate] Session.replicate() into IDENTITY table ?

[Darryl M. <dar...@ne...>]

Steve Ebersole wrote:
> 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.

The use of a strategy configuration object would fine from the Hibernate 
API users perspective and head off the possibility of legacy API kruft 
issues (when another parameter is wanted in the future).


Would I be correct in saying that operations using a StatelessSession 
are not part of a transaction ?  If so are you proposing to _REMOVE_ the 
Session#replicate() operation completely that is part of a transaction. 
  Providing for both stateful and stateless would cover all bases and 
have their valid use cases.  Maybe I am misunderstanding something here.

Darryl