You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jdo-dev@db.apache.org by Craig L Russell <Cr...@Sun.COM> on 2006/07/24 07:01:47 UTC
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:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!