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!
