Mail list migration complete
by Steve Ebersole
Migration of the Hibernate email lists to their new hosting home is now
complete. As of today, automated emails have been fully cut over:
JIRA -> hibernate-issues(a)lists.jboss.org
SVN -> hibernate-commits(a)lists.jboss.org
CruiseControl -> hibernate-dev(a)lists.jboss.org
For the past 2 weeks or so I have been monitoring both of the dev lists.
As of next week, that will stop and I will only continue to subscribe to
hibernate-dev(a)lists.jboss.org
The hibernate-announce(a)lists.jboss.org is new and we'll see how it goes.
It is supposed to be used for general announcements, release
notifications, etc. For example, I intend to send release announcements
to both hibernate-announce(a)lists.jboss.org and
hibernate-dev@lists.jboss.org...
Thanks!
Steve
19 years, 8 months
RE: [Hibernate] Session.replicate() into IDENTITY table ?
by Steve Ebersole
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:darryl-mailinglists@netbauds.net]
Sent: Friday, August 11, 2006 3:13 AM
To: Steve Ebersole
Cc: hibernate-devel(a)lists.sourceforge.net
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() ...
> /**
> * 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
19 years, 8 months
RE: [hibernate-dev] Does anybody read this list? Esp Steve
by Steve Ebersole
I still read both as of right now.
-----Original Message-----
From: hibernate-dev-bounces(a)lists.jboss.org
[mailto:hibernate-dev-bounces@lists.jboss.org] On Behalf Of Emmanuel
Bernard
Sent: Wednesday, August 09, 2006 4:28 PM
To: hibernate-dev(a)lists.jboss.org
Subject: [hibernate-dev] Does anybody read this list? Esp Steve
Since the list system change, does anybody see it
hibernate-dev(a)lists.jboss.org
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
19 years, 8 months