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