Hi, Thanks for your reply.
>> Is this by design? > >Yes, and it's documented. See >http://castor.exolab.org/jdo-mapping.html . Point taken. Alas. >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. This is an unpalatable solution as (not unreasonably) I would rather not expose anything to a reflection test. I know there are ways around this (facade classes etc.) but I would like not to have to work around the castor engine. >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. You are probably correct. I don't know another way either, although I've only been in the business of designing JDO implementations for the duration of this email, and so have probably not thought it through completely. :) >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. This is the critical issue. The object setMethod() is called by castor when the object loaded. Castor sometimes loads objects (and notifies observers, or exectutes significant code) even if the values have not changed. This is a hypothetical situation: Assume myObject.getResource() causes a semaphore to be decremented (local or otherwise, it doesn't matter) e.g. If I load it object with myObject = (Object) db.load(Object.class , Key) Then the semaphore will be decremented and the logical activity of my system is adversely influenced by the persistence engine. >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. Yes this is a solution (I could also write a facade class), but it is looking increasingly like the persistence engine is dictating behaviour and structure to the model it is supposed to provide a service for. Regards, Darragh -----Original Message----- From: Rhett Sutphin [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 26, 2003 2:39 PM To: [EMAIL PROTECTED] Subject: Re: [castor-dev] Castor JDO serious design flaw? Hi, 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 ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
