Comments inline.
On Wednesday, February 26, 2003, at 07:49 AM, Darragh O Flanagan (EEI) wrote:
I just wanted to say that I've been using Castor JDO for a short time now,
and all seemed to be going swimmingly. It's well documented, easy to use &
combined with Castor Doclet it aids development quite nicely.
However I have noticed that the Castor JDO engine calls the setter & getter
methods for objects which I have decided should be persistent.....
Is this by design?
Yes, and it's documented. See http://castor.exolab.org/jdo-mapping.html .
The reason I ask, is of course that I would like my getter & setter method code
blocks to execute only when called by other aspects of my system.
I would argue that a persistence mechanism has no business executing
these code blocks.
If you would prefer that it read field values by direct access to the member variables, that can be accomplished using the "direct" attribute in the field mapping. Note that this requires that the member variables be public.
Otherwise, I am curious about how you would suggest the persistence mechanism gain access to the values that it will persist.
I do not know a method other than public accessors/mutators or public variables whereby a persistence engine written in 100% java and not requiring post-processing of persisted classes can access the values in an object. The "public" restrictions are imposed by the security model of java reflection.
At first this might seem like a pedantic requirement, but if I want to attach an observer to a class which has been made persistent using Castor JDO, well you can imagine....
I'm not sure I understand. If you attach an observer, don't you want it to be notified when an object's value changed? Why does it matter that it is changed by the persistence engine instead of something else? I can't imagine -- please fill me in.
Since I discovered this, I have tested it with a commercial implementation (lido)
of JDO and found that this does not happen with it. I assume the other commercial
vendors have thought of this.
N.b.: castor JDO is not an implementation of Sun's JDO spec. See http://castor.exolab.org/jdo-faq.html#Castor's-relation-to-other- specifications .
Has else anybody found this to be the case, and had similar problems? Is there a known way to prevent this happening using Castor?
A possible work around is to write castor-only accessors. That is, have two sets of methods in each object -- a set for castor and a set for your other objects. But I'm not entirely clear on the behavior you expect, so that may not be appropriate.
Rhett
-- Rhett Sutphin Research Assistant (Software) Coordinated Laboratory for Computational Genomics and the Center for Macular Degeneration University of Iowa - Iowa City, IA 52242 - USA 4111 MEBRF - email: [EMAIL PROTECTED]
----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
