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" <mbo.tech@spree.de>
To: <jdo-dev@db.apache.org>
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" <Craig.Russell@Sun.COM>
>> To: <jdo-dev@db.apache.org>
>> 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:Craig.Russell@sun.com
>>> P.S. A good JDO? O, Gasp!
>>>
>>>
>>
>> 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!
>>
>>
>>
>
>
> --
> Michael Bouschen Tech@Spree Engineering GmbH
> mailto:mbo.tech@spree.de http://www.tech.spree.de/
> Tel.:++49/30/235 520-33 Buelowstr. 66
> Fax.:++49/30/2175 2012 D-10783 Berlin
>
>
>
|