|
Home > Archive > Apache JDO Project > July 2006 > SCO and FCO treatment of String, Locale, etc.
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
SCO and FCO treatment of String, Locale, etc.
|
|
| Craig L Russell 2006-07-24, 1:11 am |
| | |
| Ilan Kirsh 2006-07-24, 1:11 am |
| 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!
| |
| Craig L Russell 2006-07-24, 7:11 am |
| | |
| Ilan Kirsh 2006-07-24, 7:11 am |
| 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 2006-07-24, 7:11 pm |
| 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:
>
>
>
> 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.
>
>
> 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.
>
>
>
> 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.
>
>
> 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
>
>
> 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
| |
| Ilan Kirsh 2006-07-24, 7:11 pm |
| 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
>
>
> --
> 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 2006-07-25, 7:11 pm |
| 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 persis
tence-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.[vbcol=seagreen]
>
> 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.
>
>
>
s possible, but I am not sure that it worth the effort, because it is rarely used.[vbcol=seagreen]
--
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
|
|
|
|
|