You are right, the getPersistenceManager() is a bad example. Of course, there
are many other examples. What to do when such a field value is an argument of
makePersistent(), deletePersistent(), makeTransient(), etc... Handling this as
a special case is possible, but I am not sure that it worth the effort, because
it is rarely used.
Actually I liked the "embedded=false" metadata because it adds a different test
case, but omitting these settings might be an alternative to clone.
Relevant metadata for instance is in:
jdo20-tck\jdo\datastoreidentity\org\apache\jdo\tck\pc\fieldtypes\FieldsOfLocale.jdo
But there are also "embedded-element=false", for instance in:
jdo20-tck\jdo\datastoreidentity\org\apache\jdo\tck\pc\fieldtypes\ArrayCollections.jdo
I don't know if there are also "embedded-key=false" and "embedded-value=false".
I can prepare a complete list if it may help.
----- Original Message -----
From: "Craig L Russell" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Monday, July 24, 2006 8:18 AM
Subject: Re: SCO and FCO treatment of String, Locale, etc.
Hi Ilan,
On Jul 24, 2006, at 12:10 AM, Ilan Kirsh wrote:
> Hi Craig,
>
> Probably this discussion is mainly theoretical because most JDO
> implementations do not support system immutable types as FCO, and
> even in implementations that do support this, the default is to use
> SCO, and this default is rarely changed (if at all). Maybe the only
> application that tries to use this optional feature is the JDOTCK,
> in which some immutable type fields are defined with embedded=false
> in the metadata.
>
> In my opinion the suggested fix in [1], at least for the fields
> that are defined with embedded=false is the right solution.
I had not understood that the tck tests in question defined
embedded=false. Changing this to "default" to allow the
implementation to choose would then be better. I'll take another look
at the test cases.
>
> Unfortunately the suggested fix to the specification might be
> insufficient because it will cause conflicts in many other places.
> For instance, what should return JDOHelper.getPersistenceManager
> (field) when a FCO immutable type field is shared by two different
> PersistenceManagers?
This is not portable behavior in any case. The specification could
define this to return null always for these cases. These instances
should not be associated with a PersistenceManager.
> What should happen when such a field value is passed as a query
> argument (according to the spec: "If a persistent instance
> associated with another PersistenceManager is passed as a
> parameter, JDOUserException is thrown during execute()"), etc.
Since there is no ambiguity as to the semantics of passing such a
reference (there is no PersistenceManager that owns the instances) no
exception needs to be thrown.
>
> The most logical solution IMO is to treat such FCO instances as any
> other FCO, and a user that chooses to use them with embedded=false
> (again, very rare) will have to use clone.
It might be better to treat such FCO instances as special cases that
are not owned by a PersistenceManager, but are shared among all
PersistenceManagers. This treatment is consistent with what at least
one object database does (having a special database representation
for fixed precision integers etc.)
Thanks,
Craig
>
> Regards,
>
> Ilan
>
> ----- Original Message -----
> From: Craig L Russell
> To: JDO Expert Group ; Apache JDO project
> Sent: Monday, July 24, 2006 7:01 AM
> Subject: SCO and FCO treatment of String, Locale, etc.
>
>
> Javadogs,
>
>
> An issue has been raised [1] with regard to storage of instances
> of immutable system object classes, e.g. Integer, String, Locale.
> The specification calls for users of the API to not depend on
> whether these instances are stored as FCO or SCO.
>
>
> The intent of the specification is that applications should not
> depend on whether the instances are stored by themselves as
> persistent instances or stored as embedded within the domain class
> instances. Furthermore, the application should not depend on FCO
> behavior: uniquing of instances in the same PersistenceManager for
> the same instance. Finally, the application should not depend on
> guaranteeing SCO behavior: copying the instance upon commit and
> guaranteeing a distinct instance in memory upon reinstantiation.
>
>
> The rationale of this wording was specifically to allow an
> implementation of JDO to either store instances embedded in the
> "containing" domain class instance or as a nullable reference to a
> persistence-capable System class in the datastore, as is done by
> some object databases.
>
>
> The intent was not to impose restrictions on the application's
> use of the identical instance as the value of multiple fields of
> domain classes. A literal interpretation of this part of the
> specification would require users to guarantee that the same
> instance of any of the classes was never contained in instances
> managed by multiple PersistenceManagers. The effect of this
> interpretation is to require cloning for each instance of Integer,
> String, Locale, etc. used in domain classes.
>
>
> I believe that this interpretation should be disallowed by the
> specification, as it imposes a great burden on users. I would like
> the Expert Group to discuss this issue and straw proposal.
>
>
> <spec 6.4.3>
> Immutable Object Class types
> JDO implementations must support fields that reference instances
> of immutable object
> classes, and may choose to support these instances as SCOs or FCOs:
> •package java.lang: Boolean, Character, Byte, Short, Integer, Long,
> Float, Double, and String;
> •package java.util: Locale, Currency.
> •package java.math: BigDecimal, BigInteger.
> Portable JDO applications must not depend on whether instances of
> these classes are treat-
> ed as SCOs or FCOs.
> </spec 6.4.3>
>
>
> <proposed 6.4.3>
> Immutable Object Class types
> JDO implementations must support fields that reference instances
> of immutable object
> classes, and may choose to support these instances as SCOs or FCOs:
> •package java.lang: Boolean, Character, Byte, Short, Integer, Long,
> Float, Double, and String;
> •package java.util: Locale, Currency.
> •package java.math: BigDecimal, BigInteger.
> Portable JDO applications must not depend on SCO or FCO uniquing
> behavior, nor on the storage mechanism in the datastore. Portable
> applications may use the same instance of these classes as field
> values in any persistence-capable class instance.
> </proposed 6.4.3>
>
>
> [1]http://issues.apache.org/jira/browse/JDO-397?page=all
>
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/
> products/jdo
> 408 276-5638 mailto:[EMAIL PROTECTED]
> P.S. A good JDO? O, Gasp!
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
