Re: [Hibernate] Session.replicate() into IDENTITY table ?
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 - 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
Re: [Hibernate] Session.replicate() into IDENTITY table ?
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:[EMAIL PROTECTED]
Sent: Friday, August 11, 2006 3:13 AM
To: Steve Ebersole
Cc: hibernate-devel@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?
> *
> * 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
-
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
Re: [Hibernate] Session.replicate() into IDENTITY table ?
StatelessSession has nothing to do with lack of a transaction!
-Original Message-
From: Darryl Miles [mailto:[EMAIL PROTECTED]
Sent: Friday, August 11, 2006 3:13 AM
To: Steve Ebersole
Cc: hibernate-devel@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?
> *
> * 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
-
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
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?
> *
> * 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
-
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
Re: [Hibernate] Session.replicate() into IDENTITY table ?
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?
*
* 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
[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/msg05230.html http://forum.hibernate.org/viewtopic.php?t=949574&highlight= http://www.hibernate.org/hib_docs/v3/api/org/hibernate/Session.html#replicate(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=DEVDEV ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
[Hibernate] Session.replicate() into IDENTITY table ?
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
