I think the best approach is to treat embedded objects as transient for all of the life cycle interrogatives. Then there is no question about expected behavior after evict, commit, etc.
This does impact design. If you choose to make an embedded object, then that object only has persistent behavior when associated with an owner. It's never dirty, and can't be the parameter of any of the life cycle changing APIs.
Craig On May 26, 2009, at 3:14 AM, Christiaan wrote:
Does this need to be addressed in the spec? Personally I feel that this technical design issue really impacts the decision of a designer whether a class should be embedded or not, whereas I think it should be a conceptualdecision whether a class should be embedded or not. So making it more explicit in the spec would at least be one thing to do. -- View this message in context: http://www.nabble.com/Embedded-object-and-evict-tp22738918p23720315.html Sent from the JDO - Development mailing list archive at Nabble.com.
Craig L Russell Architect, Sun Java Enterprise System http://db.apache.org/jdo 408 276-5638 mailto:[email protected] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
