Hi again,
<snip>
>
> >
> > My argument here is that the JDO spec does not contain an Identity
> > object. It does also not contain any formal contract
> between Identity
> > objects and the PersistencecManager.
> >
> > So using Identity.serialize() is not against the JDO.
> >
>
> Here I'm not agree with you.
> In the specification the JDO Helper allows you to get the Identity
> object of a persistent object via the
> getObjectId(java.lang.Object pc)
> method. This method returns a java.lang.Object (to let JDO vendors
> define their own Object Identity, for OJB : o.a.ojb.broker.Identity).
i agree.
>
> The newObjectIdInstance(java.lang.Class pcClass,
> java.lang.String str)
> of the PersistenceManager Class allows to create again an Identity
> Object from a String str.
> This string can comes from getObjectId(java.lang.Object
> pc).toString().
> JDO spec : "The String argument might have been the result of
> executing
> toString on an object id instance."
I know this section. The phrase "might have been" does not sound like
something essential or mandatory for me.
It's simply an example for the mechanism, but no real contract!
> The method toString is define for all java Objects, so, in this case,
> the code is portable. There is no need to cast to a JDO
> Vendor specific
> type.
> I tryed other JDO implementations and the awaited behaviour is that
> which I describe above.
OK, this is a valid argument. I'll think about a solution.
I'm reluctant to invest any time into the Parser. Maybe we can get off with
a simple renaming of methods as you suggested.
Needs a closer look at the code. I'll keep you updated.
Thomas
>
> >> So, if one want to use ObjectId with JDO, its software
> application is
> >> dependant on OJB and can't be used with another OJB implementation.
> >
> >
> > It becomes dependend by using OJB Identity objects already!
> Different
> > JDO implementations will use diffent Identity concepts!
>
> Yes, but there is no need to cast in a specific type because
> the method
> toString() works fine with Identity!
>
> >
> >> I think it could be usefull to rename the
> Identity.toString() method and
> >> to implement a new Identity.toString() method :
> >>
> >> public String toString()
> >> {
> >> return new String( serialize() );
> >> }
> >>
> >> In this case, OJB will become JDO compliant with ObjectId.
> >> I don't know if the actual Identity.toString() method is
> often used
> >> but I think rename this method will not change a big part
> of OJB. Am I
> >> wrong?
> >
> >
> > Identity.toString() is used to produce a human readable
> representation
> > of an Identity. It is used in this way in several places.
> > So IMO it's not an option to change the semantics of toString().
> >
> > The "real" solution could be to provide a Parser that can build
> > Indentities from the Identity.toSTring() representation.
> > But that's a lot of work and the benefit is rather small, as using
> > serialize() is not a violation of the JDO spec IMO.
>
> I think this work is very important. Benefits are portability!!
> I think it's an important part of OpenSource projects.
>
> Regards.
>
>
> --
> Christophe Demarey,
> Research engineer
> OpenCCM project - http://www.objectweb.org/openccm
> GOAL Team - CNRS/USTL/LIFL - http://www.lifl.fr/GOAL/
> Universite des Sciences et Technologies de Lille
> LIFL - UMR CNRS 8022- Batiment M3
> 59655 Villeneuve d'Ascq Cedex - FRANCE
> Phone: +33 (0)32043 4728
> Fax : +33 (0)32043 6566
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
