db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ilan Kirsh <ki...@objectdb.com>
Subject Re: SCO and FCO treatment of String, Locale, etc.
Date Mon, 24 Jul 2006 07:10:51 GMT
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.

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? 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.

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.

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:Craig.Russell@sun.com
  P.S. A good JDO? O, Gasp!


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message