Hi Michael, Following is the statement from page 228: "It must be specified or default to "true" for fields of primitive types, wrappers, java.lang, java.math, java.util, collection, map, and array types specified above; and “false” for other types including persistence-capable types, interface types and the Object type."
The "must" word is confusing but I don't think that it indicates that "embedded=false" is forbidden for some types, otherwise "embedded=true" is forbidden for the other types, and actually only the default is allowed. Anyway, the combination of "embedded=false" and using same (non cloned) Locale instances with different PersistenceManagers is against the current spec (assuming that "embedded=false" is a hint to use FCO rather than SCO). Either removing the "embedded=false" or using clone should solve the problem. Thanks, Ilan ---- Original Message ----- From: "Michael Bouschen" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Monday, July 24, 2006 9:49 PM Subject: Re: SCO and FCO treatment of String, Locale, etc. > Hi Ilan, > > I think specifying embedded=false for a field of type Locale, String, > Integer, etc. is not according to the spec. Chapter 18.5 on page 228 > defines that embedded must be specified or default to true for such > fields. This means a couple of .jdo file in the fieldtypes directory > have a bug and need to be updated. > > The downside of the solution proposed in JDO-397 is that I need to clone > the values before I can use them as field values. So the following code > would fail, because it uses the same string for pc instances bound to > different PMs. To make this code portable I need to clone the string. > > public static final String FIRSTNAME = "Michael"; > ... > emplyoee1.setFirstname(FIRSTNAME); > pm1.makePersistent(employee1); > emplyoee2.setFirstname(FIRSTNAME); > pm2.makePersistent(employee2); > > Craig's suggested fix to the specification would allow the above code > fragment to work with a JDO implementation no matter if the JDO > implementation treats a String as FCO or SCO. > > What do you think? > > Regards Michael >> 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! >> >> >> > > > -- > Michael Bouschen [EMAIL PROTECTED] Engineering GmbH > mailto:[EMAIL PROTECTED] http://www.tech.spree.de/ > Tel.:++49/30/235 520-33 Buelowstr. 66 > Fax.:++49/30/2175 2012 D-10783 Berlin > > >
