db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Bouschen <mbo.t...@spree.de>
Subject Re: SCO and FCO treatment of String, Locale, etc.
Date Tue, 25 Jul 2006 21:14:51 GMT
Hi Ilan,

good point. I must admit I read this paragraph that embedded=false is 
not allowed for some types. But you are right this would imply that 
embedded=false is the only possible setting for fields of pc types and 
this does not make sense. So maybe we need to clarify this in the spec.

Regards Michael

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


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


Mime
View raw message