You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jdo-dev@db.apache.org by Craig L Russell <Cr...@Sun.COM> on 2005/12/06 18:52:10 UTC
VOTE [URGENT] Issue 136: Change signature of makePersistent
Javadogs,
I'd like to tally the vote on this issue by close of business
Thursday 8-Dec-2005.
This issue was renamed to highlight the interface change.
Please vote to adopt this proposal or offer a reason to reject it.
It's the most significant change for a few months, as it modifies the
core method of persistence.
Rationale: There are so few differences between makePersistent and
attachCopy, it's confusing. The only significant differences between
the APIs is in the treatment of transient instances. MakePersistent
makes transient instances transition to persistent-new; attachCopy
copies transient instances.
The proposal is to remove attachCopy, change the signature of
makePersistent and makePersistentAll to return the instance(s).
The semantics of makePersistent change slightly from the
specification. Currently, detached instances in the object graph
cause an exception to be thrown. With this change, detached instances
are located in the persistent cache and any dirty fields are applied
to the persistent instance.
With this change, there is no standard way to attach the same object
graph to multiple persistence managers. If this becomes an issue, we
can consider adding a method to JDOHelper that copies a complete
object graph so the copies can be attached to multiple persistence
managers. But practical experience has not shown this to be an issue.
<proposed 12.6.7>
Object makePersistent (Object pc);
Object [] makePersistentAll (Object[] pcs);
Collection makePersistentAll (Collection pcs);
A12.5.7-6A [These methods make transient instances persistent and
apply detached instance changes to the cache. They must be called in
the context of an active transaction, or a JDOUserException is
thrown.] A12.5.7-6B [For a transient instance, they will assign an
object identity to the instance and transition it to persistent-new.]
Any transient instances reachable from this instance via persistent
fields of this instance will become provisionally persistent,
transitively. That is, they behave as persistent-new instances
(return true to isPersistent, isNew, and isDirty). But A12.5.7-6C [at
commit time, the reachability algorithm is run again, and instances
made provisionally persistent that are not currently reachable from
persistent instances will revert to transient.]
For a detached instance, they locate or create a persistent instance
with the same JDO identity as the detached instance, and merge the
persistent state of the detached instance to the persistent instance.
Only the state of persistent fields is merged. If non-persistent
state needs to be copied, the application should use the
jdoPostAttach callback or the postAttach lifecycle event listener.
Any references to the detached instances from instances in the
closure of the parameter instances are modified to refer to the
corresponding persistent instance instead of to the detached instance.
During application of changes of the detached state, if the JDO
implementation can determine that there were no changes made during
detachment, then the implementation is not required to mark the
corresponding instance dirty. A12.6.8-28 [If it cannot determine if
changes were made, then it must mark the instance dirty.]
No consistency checking is done during makePersistent. If consistency
checking is required by the application, then flush or
checkConsistency should be called after attaching the instances.
A12.5.7-7 [These methods have no effect on parameter persistent
instances already managed by this PersistenceManager.] A12.5.7-8
[They will throw a JDOUserException if the parameter instance is
managed by a different PersistenceManager.]
A12.6.7-1 [If an instance is of a class whose identity type
(application, datastore, or none) is not supported by the JDO
implementation, then a JDOUserException will be thrown for that
instance.]
The return value for instances in the transient or persistent states
is the same as the parameter value. The return value for detached
instances is the persistent instance corresponding to the detached
instance.
The return values for makePersistentAll methods correspond by
position to the parameter instances.
</spec 12.6.7>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: VOTE [URGENT] Issue 136: Change signature of makePersistent
Posted by David Ezzio <de...@bea.com>.
+1
Re: VOTE [URGENT] Issue 136: Change signature of makePersistent
Posted by Wes Biggs <we...@tralfamadore.com>.
+1 (still)
Re: VOTE [URGENT] Issue 136: Change signature of makePersistent
Posted by Abe White <aw...@bea.com>.
+1
Re: VOTE [URGENT] Issue 136: Change signature of makePersistent
Posted by Michael Bouschen <mb...@spree.de>.
Hi Craig,
+1 to adopt the proposal.
Regards Michael
> Javadogs,
>
> I'd like to tally the vote on this issue by close of business Thursday
> 8-Dec-2005.
>
> This issue was renamed to highlight the interface change.
>
> Please vote to adopt this proposal or offer a reason to reject it. It's
> the most significant change for a few months, as it modifies the core
> method of persistence.
>
> Rationale: There are so few differences between makePersistent and
> attachCopy, it's confusing. The only significant differences between the
> APIs is in the treatment of transient instances. MakePersistent makes
> transient instances transition to persistent-new; attachCopy copies
> transient instances.
>
> The proposal is to remove attachCopy, change the signature of
> makePersistent and makePersistentAll to return the instance(s).
>
> The semantics of makePersistent change slightly from the specification.
> Currently, detached instances in the object graph cause an exception to
> be thrown. With this change, detached instances are located in the
> persistent cache and any dirty fields are applied to the persistent
> instance.
>
> With this change, there is no standard way to attach the same object
> graph to multiple persistence managers. If this becomes an issue, we can
> consider adding a method to JDOHelper that copies a complete object
> graph so the copies can be attached to multiple persistence managers.
> But practical experience has not shown this to be an issue.
>
> <proposed 12.6.7>
> Object makePersistent (Object pc);
> Object [] makePersistentAll (Object[] pcs);
> Collection makePersistentAll (Collection pcs);
> A12.5.7-6A [These methods make transient instances persistent and apply
> detached instance changes to the cache. They must be called in the
> context of an active transaction, or a JDOUserException is thrown.]
> A12.5.7-6B [For a transient instance, they will assign an object
> identity to the instance and transition it to persistent-new.] Any
> transient instances reachable from this instance via persistent fields
> of this instance will become provisionally persistent, transitively.
> That is, they behave as persistent-new instances (return true to
> isPersistent, isNew, and isDirty). But A12.5.7-6C [at commit time, the
> reachability algorithm is run again, and instances made provisionally
> persistent that are not currently reachable from persistent instances
> will revert to transient.]
> For a detached instance, they locate or create a persistent instance
> with the same JDO identity as the detached instance, and merge the
> persistent state of the detached instance to the persistent instance.
> Only the state of persistent fields is merged. If non-persistent state
> needs to be copied, the application should use the jdoPostAttach
> callback or the postAttach lifecycle event listener. Any references to
> the detached instances from instances in the closure of the parameter
> instances are modified to refer to the corresponding persistent instance
> instead of to the detached instance.
> During application of changes of the detached state, if the JDO
> implementation can determine that there were no changes made during
> detachment, then the implementation is not required to mark the
> corresponding instance dirty. A12.6.8-28 [If it cannot determine if
> changes were made, then it must mark the instance dirty.]
> No consistency checking is done during makePersistent. If consistency
> checking is required by the application, then flush or checkConsistency
> should be called after attaching the instances.
> A12.5.7-7 [These methods have no effect on parameter persistent
> instances already managed by this PersistenceManager.] A12.5.7-8 [They
> will throw a JDOUserException if the parameter instance is managed by a
> different PersistenceManager.]
> A12.6.7-1 [If an instance is of a class whose identity type
> (application, datastore, or none) is not supported by the JDO
> implementation, then a JDOUserException will be thrown for that instance.]
> The return value for instances in the transient or persistent states is
> the same as the parameter value. The return value for detached instances
> is the persistent instance corresponding to the detached instance.
> The return values for makePersistentAll methods correspond by position
> to the parameter instances.
> </spec 12.6.7>
>
>
> Craig Russell
>
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
>
> 408 276-5638 mailto:Craig.Russell@sun.com
>
> P.S. A good JDO? O, Gasp!
>
>
--
Michael Bouschen Tech@Spree Engineering GmbH
mailto:mbo.tech@spree.de http://www.tech.spree.de/
Tel.:++49/30/235 520-33 Buelowstr. 66
Fax.:++49/30/2175 2012 D-10783 Berlin
RE: VOTE [URGENT] Issue 136: Change signature of makePersistent
Posted by "Matthew T. Adams" <ma...@xcalia.com>.
+1, but you probably already knew that. :)
-----Original Message-----
From: Craig.Russell@Sun.COM [mailto:Craig.Russell@Sun.COM]
Sent: Tuesday, December 06, 2005 9:52 AM
To: JDO Expert Group; Apache JDO project
Subject: VOTE [URGENT] Issue 136: Change signature of makePersistent
Javadogs,
I'd like to tally the vote on this issue by close of business Thursday
8-Dec-2005.
This issue was renamed to highlight the interface change.
Please vote to adopt this proposal or offer a reason to reject it. It's the
most significant change for a few months, as it modifies the core method of
persistence.
Rationale: There are so few differences between makePersistent and
attachCopy, it's confusing. The only significant differences between the
APIs is in the treatment of transient instances. MakePersistent makes
transient instances transition to persistent-new; attachCopy copies
transient instances.
The proposal is to remove attachCopy, change the signature of makePersistent
and makePersistentAll to return the instance(s).
The semantics of makePersistent change slightly from the specification.
Currently, detached instances in the object graph cause an exception to be
thrown. With this change, detached instances are located in the persistent
cache and any dirty fields are applied to the persistent instance.
With this change, there is no standard way to attach the same object graph
to multiple persistence managers. If this becomes an issue, we can consider
adding a method to JDOHelper that copies a complete object graph so the
copies can be attached to multiple persistence managers. But practical
experience has not shown this to be an issue.
<proposed 12.6.7>
Object makePersistent (Object pc);
Object [] makePersistentAll (Object[] pcs);
Collection makePersistentAll (Collection pcs);
A12.5.7-6A [These methods make transient instances persistent and apply
detached instance changes to the cache. They must be called in the context
of an active transaction, or a JDOUserException is thrown.] A12.5.7-6B [For
a transient instance, they will assign an object identity to the instance
and transition it to persistent-new.] Any transient instances reachable from
this instance via persistent fields of this instance will become
provisionally persistent, transitively. That is, they behave as
persistent-new instances (return true to isPersistent, isNew, and isDirty).
But A12.5.7-6C [at commit time, the reachability algorithm is run again, and
instances made provisionally persistent that are not currently reachable
from persistent instances will revert to transient.]
For a detached instance, they locate or create a persistent instance with
the same JDO identity as the detached instance, and merge the persistent
state of the detached instance to the persistent instance. Only the state of
persistent fields is merged. If non-persistent state needs to be copied, the
application should use the jdoPostAttach callback or the postAttach
lifecycle event listener. Any references to the detached instances from
instances in the closure of the parameter instances are modified to refer to
the corresponding persistent instance instead of to the detached instance.
During application of changes of the detached state, if the JDO
implementation can determine that there were no changes made during
detachment, then the implementation is not required to mark the
corresponding instance dirty. A12.6.8-28 [If it cannot determine if changes
were made, then it must mark the instance dirty.]
No consistency checking is done during makePersistent. If consistency
checking is required by the application, then flush or checkConsistency
should be called after attaching the instances.
A12.5.7-7 [These methods have no effect on parameter persistent instances
already managed by this PersistenceManager.] A12.5.7-8 [They will throw a
JDOUserException if the parameter instance is managed by a different
PersistenceManager.]
A12.6.7-1 [If an instance is of a class whose identity type (application,
datastore, or none) is not supported by the JDO implementation, then a
JDOUserException will be thrown for that instance.]
The return value for instances in the transient or persistent states is the
same as the parameter value. The return value for detached instances is the
persistent instance corresponding to the detached instance.
The return values for makePersistentAll methods correspond by position to
the parameter instances.
</spec 12.6.7>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: VOTE [URGENT] Issue 136: Change signature of makePersistent
Posted by Geoff hendrey <ge...@yahoo.com>.
+1
--- Craig L Russell <Cr...@Sun.COM> wrote:
> Javadogs,
>
> I'd like to tally the vote on this issue by close of
> business
> Thursday 8-Dec-2005.
>
> This issue was renamed to highlight the interface
> change.
>
> Please vote to adopt this proposal or offer a reason
> to reject it.
> It's the most significant change for a few months,
> as it modifies the
> core method of persistence.
>
> Rationale: There are so few differences between
> makePersistent and
> attachCopy, it's confusing. The only significant
> differences between
> the APIs is in the treatment of transient instances.
> MakePersistent
> makes transient instances transition to
> persistent-new; attachCopy
> copies transient instances.
>
> The proposal is to remove attachCopy, change the
> signature of
> makePersistent and makePersistentAll to return the
> instance(s).
>
> The semantics of makePersistent change slightly from
> the
> specification. Currently, detached instances in the
> object graph
> cause an exception to be thrown. With this change,
> detached instances
> are located in the persistent cache and any dirty
> fields are applied
> to the persistent instance.
>
> With this change, there is no standard way to attach
> the same object
> graph to multiple persistence managers. If this
> becomes an issue, we
> can consider adding a method to JDOHelper that
> copies a complete
> object graph so the copies can be attached to
> multiple persistence
> managers. But practical experience has not shown
> this to be an issue.
>
> <proposed 12.6.7>
> Object makePersistent (Object pc);
> Object [] makePersistentAll (Object[] pcs);
> Collection makePersistentAll (Collection pcs);
> A12.5.7-6A [These methods make transient instances
> persistent and
> apply detached instance changes to the cache. They
> must be called in
> the context of an active transaction, or a
> JDOUserException is
> thrown.] A12.5.7-6B [For a transient instance, they
> will assign an
> object identity to the instance and transition it to
> persistent-new.]
> Any transient instances reachable from this instance
> via persistent
> fields of this instance will become provisionally
> persistent,
> transitively. That is, they behave as persistent-new
> instances
> (return true to isPersistent, isNew, and isDirty).
> But A12.5.7-6C [at
> commit time, the reachability algorithm is run
> again, and instances
> made provisionally persistent that are not currently
> reachable from
> persistent instances will revert to transient.]
> For a detached instance, they locate or create a
> persistent instance
> with the same JDO identity as the detached instance,
> and merge the
> persistent state of the detached instance to the
> persistent instance.
> Only the state of persistent fields is merged. If
> non-persistent
> state needs to be copied, the application should use
> the
> jdoPostAttach callback or the postAttach lifecycle
> event listener.
> Any references to the detached instances from
> instances in the
> closure of the parameter instances are modified to
> refer to the
> corresponding persistent instance instead of to the
> detached instance.
> During application of changes of the detached state,
> if the JDO
> implementation can determine that there were no
> changes made during
> detachment, then the implementation is not required
> to mark the
> corresponding instance dirty. A12.6.8-28 [If it
> cannot determine if
> changes were made, then it must mark the instance
> dirty.]
> No consistency checking is done during
> makePersistent. If consistency
> checking is required by the application, then flush
> or
> checkConsistency should be called after attaching
> the instances.
> A12.5.7-7 [These methods have no effect on parameter
> persistent
> instances already managed by this
> PersistenceManager.] A12.5.7-8
> [They will throw a JDOUserException if the parameter
> instance is
> managed by a different PersistenceManager.]
> A12.6.7-1 [If an instance is of a class whose
> identity type
> (application, datastore, or none) is not supported
> by the JDO
> implementation, then a JDOUserException will be
> thrown for that
> instance.]
> The return value for instances in the transient or
> persistent states
> is the same as the parameter value. The return value
> for detached
> instances is the persistent instance corresponding
> to the detached
> instance.
> The return values for makePersistentAll methods
> correspond by
> position to the parameter instances.
> </spec 12.6.7>
>
>
> Craig Russell
> Architect, Sun Java Enterprise System
> http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>
__________________________________________
Yahoo! DSL Something to write home about.
Just $16.99/mo. or less.
dsl.yahoo.com
Re: VOTE [URGENT] Issue 136: Change signature of makePersistent
Posted by Bin Sun <su...@yahoo.com>.
agree
--- Craig L Russell <Cr...@Sun.COM> wrote:
> Javadogs,
>
> I'd like to tally the vote on this issue by close of
> business
> Thursday 8-Dec-2005.
>
> This issue was renamed to highlight the interface
> change.
>
> Please vote to adopt this proposal or offer a reason
> to reject it.
> It's the most significant change for a few months,
> as it modifies the
> core method of persistence.
>
> Rationale: There are so few differences between
> makePersistent and
> attachCopy, it's confusing. The only significant
> differences between
> the APIs is in the treatment of transient instances.
> MakePersistent
> makes transient instances transition to
> persistent-new; attachCopy
> copies transient instances.
>
> The proposal is to remove attachCopy, change the
> signature of
> makePersistent and makePersistentAll to return the
> instance(s).
>
> The semantics of makePersistent change slightly from
> the
> specification. Currently, detached instances in the
> object graph
> cause an exception to be thrown. With this change,
> detached instances
> are located in the persistent cache and any dirty
> fields are applied
> to the persistent instance.
>
> With this change, there is no standard way to attach
> the same object
> graph to multiple persistence managers. If this
> becomes an issue, we
> can consider adding a method to JDOHelper that
> copies a complete
> object graph so the copies can be attached to
> multiple persistence
> managers. But practical experience has not shown
> this to be an issue.
>
> <proposed 12.6.7>
> Object makePersistent (Object pc);
> Object [] makePersistentAll (Object[] pcs);
> Collection makePersistentAll (Collection pcs);
> A12.5.7-6A [These methods make transient instances
> persistent and
> apply detached instance changes to the cache. They
> must be called in
> the context of an active transaction, or a
> JDOUserException is
> thrown.] A12.5.7-6B [For a transient instance, they
> will assign an
> object identity to the instance and transition it to
> persistent-new.]
> Any transient instances reachable from this instance
> via persistent
> fields of this instance will become provisionally
> persistent,
> transitively. That is, they behave as persistent-new
> instances
> (return true to isPersistent, isNew, and isDirty).
> But A12.5.7-6C [at
> commit time, the reachability algorithm is run
> again, and instances
> made provisionally persistent that are not currently
> reachable from
> persistent instances will revert to transient.]
> For a detached instance, they locate or create a
> persistent instance
> with the same JDO identity as the detached instance,
> and merge the
> persistent state of the detached instance to the
> persistent instance.
> Only the state of persistent fields is merged. If
> non-persistent
> state needs to be copied, the application should use
> the
> jdoPostAttach callback or the postAttach lifecycle
> event listener.
> Any references to the detached instances from
> instances in the
> closure of the parameter instances are modified to
> refer to the
> corresponding persistent instance instead of to the
> detached instance.
> During application of changes of the detached state,
> if the JDO
> implementation can determine that there were no
> changes made during
> detachment, then the implementation is not required
> to mark the
> corresponding instance dirty. A12.6.8-28 [If it
> cannot determine if
> changes were made, then it must mark the instance
> dirty.]
> No consistency checking is done during
> makePersistent. If consistency
> checking is required by the application, then flush
> or
> checkConsistency should be called after attaching
> the instances.
> A12.5.7-7 [These methods have no effect on parameter
> persistent
> instances already managed by this
> PersistenceManager.] A12.5.7-8
> [They will throw a JDOUserException if the parameter
> instance is
> managed by a different PersistenceManager.]
> A12.6.7-1 [If an instance is of a class whose
> identity type
> (application, datastore, or none) is not supported
> by the JDO
> implementation, then a JDOUserException will be
> thrown for that
> instance.]
> The return value for instances in the transient or
> persistent states
> is the same as the parameter value. The return value
> for detached
> instances is the persistent instance corresponding
> to the detached
> instance.
> The return values for makePersistentAll methods
> correspond by
> position to the parameter instances.
> </spec 12.6.7>
>
>
> Craig Russell
> Architect, Sun Java Enterprise System
> http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>
__________________________________________
Yahoo! DSL Something to write home about.
Just $16.99/mo. or less.
dsl.yahoo.com