Margaret,
Your solution is a good one...but you can also use it for persisting the
timestamps if you want to by simply combining both your approach, and
Ben's....
public abstract class JDOBaseClass {
...
public abstract long getJDOTimeStamp();
public long jdoGetTimeStamp() {
return getJDOTimeStamp();
}
...
}
In Ben's case the source generator will automatically create the
getJDOTimeStamp implementation...
The jdoGetTimeStamp method simply delegates the call.
--Keith
P.S. Thanks for be an active user and helping others on the list.
"Martin, Margaret" wrote:
>
> Ben,
> Perhaps this is too simplistic for your needs, but for mine I simply have my
> generated classes extend a class that implements the timestamp methods. I
> don't have a need to persist the timestamps, so this works for me,
> unfortunately that may not be the case for you...
>
> Good luck -
> Margaret
>
> -----Original Message-----
> From: Ben Cox [mailto:[EMAIL PROTECTED]]
> Sent: Friday, February 15, 2002 6:10 PM
> To: [EMAIL PROTECTED]
> Subject: [castor-dev] jdoGet/SetTimeStamp
>
> We have been working toward using both the JDO and XML functionality
> of Castor on the same objects, and in particular toward either
> generation of the JDO mapping file (from the same XML Schema and/or the
> marshallable/unmarshallable source files after running the Source
> Generator), or inclusion of JDO-specific elements in the ojects that are
> generated from our schema. Currently, our approach is to create the JDO
> mapping file.
> One really surprising barrier to our implementation, which requires
> the use of long transactions, is the names of the jdoGetTimeStamp() and
> jdoSetTimeStamp() methods in the TimeStampable interface. I'm probably
> missing something, but there's no good reason I can see to step away
> from the Bean-like naming conventions of getXXX and setXXX!
> For what we're doing, that little decision seems to create a pretty
> big snag. It would be a simple matter to have the XML/JDO objects
> implement an interface with getJDOTimeStamp() and setJDOTimeStamp()
> methods, instead, because one could then simply include an attribute
> called JDOTimeStamp in the schema definition. This would result in the
> generated marshallable/unmarshallable objects, themselves, implementing
> those methods correctly without having to be hand-edited to add that
> field (god forbid!). If the method names don't start with get/set, I
> haven't seen any simple way to coerce the SourceGenerator to create them
> from the schema, so it looks like we may have to hand-edit after all!
> A grep in /src/ shows that these methods of the TimeStampable
> interface are only ever called by org.exolab.castor.persist.ClassMolder,
> (and about five of the test classes), so perhaps it would not be a big
> deal to change these method names? Or, for backward compatibility,
> provide this interface separately and rewrite the four calls to add a
> check and cast (to TimeStampable or, say, TimeStampBeanable) before
> checking or setting a timestamp.
> I'd rather not have to mangle my own copy of Castor to make this
> work, becuase that's not exactly a maintainable approach, but it might
> prove better than editing all that generated code! Is it likely that
> this is going to be cleared up in a future release? Or, is there a
> compelling reason I'm failing to see not to use bean-like method names?
> Has anyone else faced this problem yet, and perhaps know another
> (maintainable) way to get around this?
> Thanks for any advice,
>
> Ben Cox && Tim Ruppert
>
> -----------------------------------------------------------
> 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
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
