You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jdo-dev@db.apache.org by Craig L Russell <Cr...@Sun.COM> on 2006/01/03 00:48:49 UTC
[VOTE] Issue 139: Add attribute field-type to element field
Another vote on this proposal. I've added the ability to specify
multiple comma-delimited types to element-type, key-type, value-type,
and field-type but specified that this is not portable.
Issue 139:
This would allow more specific field type to be specified at
deployment time compared to compile time. For example, a field of
type Object could be specified in the jdo metadata as containing only
instances of type SimpleClass.
<proposal>
18.14 ELEMENT field
<!ATTLIST field field-type CDATA #IMPLIED>
The field-type attribute is used to specify a more restrictive type
than the field definition in the class. This might be required in
order to map the field to the datastore. To be portable, specify the
name of a single type that is itself able to be mapped to the
datastore (e.g. a field of type Object can specify field-
type=”Integer”). To specify multiple types that the field might
contain, use a comma-separated list of types, although this cannot be
portably mapped.
18.14.1ELEMENT collection
element-type
The element-type attribute specifies the type of the elements. The
type name uses Java language rules for naming: if no package is
included in the name, the package name is assumed to be the same
package as the persistence-capable class. Inner classes are
identified by the "$" marker. Classes Boolean, Byte, Character,
Double, Float, Integer, Long, Number, Object, Short, String, and
StringBuffer are treated exactly as in the Java language: they are
first checked to see if they are in the package in which they are
used, and if not, assumed to be in the java.lang package. To be
portable, specify the name of a single type that is itself able to be
mapped to the datastore (e.g. a field of type Object can specify
field-type=”Integer”). To specify multiple types that the field might
contain, use a comma-separated list of types, although this cannot be
portably mapped.
18.14.2 ELEMENT map
The key-type and value-type attributes specify the types of the key
and value, respectively. They follow the same rules as element-type
in element collection.
18.14.3 ELEMENT array
The element-type attribute is used to specify a more restrictive type
than the field definition in the class. This might be required in
order to map the field to the datastore. It follows the same rules as
element-type in element collection.
</proposal>
Craig
On Dec 28, 2005, at 1:33 PM, Michael Bouschen wrote:
> Hi Craig,
>
>> Hi Andy,
>>
>> I don't have a problem with using the element-type to be a comma-
>> separated list as a vendor extension, but in general there is no
>> way to map a heterogeneous (Object or interface type) field.
>
> does this apply the metadata attributes field-type, element-type,
> key-type and value-type?
>
>>
>> So I don't think that we should specify the comma-separated list
>> of possible types as a standard technique.
>>
>> What do others think about this?
>
> I think support for a field with multiple types in its field-type
> attribute should not be required. But maybe it makes sense to
> specify the syntax as a comma separated list of type names in case
> a JDO implementation does support this feature.
>
> Regards Michael
>
>>
>> Craig
>>
>> On Dec 21, 2005, at 12:11 AM, Andy Jefferson wrote:
>>
>>> Hi Craig,
>>>
>>>> This proposal would allow more specific field type to be
>>>> specified at
>>>> deployment time compared to compile time. For example, a field of
>>>> type Object could be specified in the jdo metadata as containing
>>>> only
>>>> instances of type SimpleClass.
>>>
>>>
>>> I don't read the proposal as saying that the user should specify
>>> the type(s) as comma-separated if they want a field declared as
>>> Object to store class A or class B or class C. What does the user
>>> do when they have a field declared as Object and want to do this ?
>>>
>>>
>>> --
>>> Andy
>>
>>
>> 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
>
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!
Re: [VOTE] Issue 139: Add attribute field-type to element field
Posted by Andy Jefferson <an...@jpox.org>.
> Another vote on this proposal. I've added the ability to specify
> multiple comma-delimited types to element-type, key-type, value-type,
> and field-type but specified that this is not portable.
+1
--
Andy
Re: [VOTE] Issue 139: Add attribute field-type to element field
Posted by Michael Bouschen <mb...@spree.de>.
Hi Craig,
+1
Regards Michael
> Another vote on this proposal. I've added the ability to specify
> multiple comma-delimited types to element-type, key-type, value-type,
> and field-type but specified that this is not portable.
>
>
> Issue 139:
>
> This would allow more specific field type to be specified at deployment
> time compared to compile time. For example, a field of type Object could
> be specified in the jdo metadata as containing only instances of type
> SimpleClass.
>
> <proposal>
> 18.14 ELEMENT field
> <!ATTLIST field field-type CDATA #IMPLIED>
> The field-type attribute is used to specify a more restrictive type than
> the field definition in the class. This might be required in order to
> map the field to the datastore. To be portable, specify the name of a
> single type that is itself able to be mapped to the datastore (e.g. a
> field of type Object can specify field-type=”Integer”). To specify
> multiple types that the field might contain, use a comma-separated list
> of types, although this cannot be portably mapped.
> 18.14.1ELEMENT collection
> element-type
> The element-type attribute specifies the type of the elements. The type
> name uses Java language rules for naming: if no package is included in
> the name, the package name is assumed to be the same package as the
> persistence-capable class. Inner classes are identified by the "$"
> marker. Classes Boolean, Byte, Character, Double, Float, Integer, Long,
> Number, Object, Short, String, and StringBuffer are treated exactly as
> in the Java language: they are first checked to see if they are in the
> package in which they are used, and if not, assumed to be in the
> java.lang package. To be portable, specify the name of a single type
> that is itself able to be mapped to the datastore (e.g. a field of type
> Object can specify field-type=”Integer”). To specify multiple types that
> the field might contain, use a comma-separated list of types, although
> this cannot be portably mapped.
> 18.14.2 ELEMENT map
> The key-type and value-type attributes specify the types of the key and
> value, respectively. They follow the same rules as element-type in
> element collection.
> 18.14.3 ELEMENT array
> The element-type attribute is used to specify a more restrictive type
> than the field definition in the class. This might be required in order
> to map the field to the datastore. It follows the same rules as
> element-type in element collection.
> </proposal>
>
> Craig
>
> On Dec 28, 2005, at 1:33 PM, Michael Bouschen wrote:
>
>> Hi Craig,
>>
>>> Hi Andy,
>>>
>>> I don't have a problem with using the element-type to be a
>>> comma-separated list as a vendor extension, but in general there is
>>> no way to map a heterogeneous (Object or interface type) field.
>>
>>
>> does this apply the metadata attributes field-type, element-type,
>> key-type and value-type?
>>
>>>
>>> So I don't think that we should specify the comma-separated list of
>>> possible types as a standard technique.
>>>
>>> What do others think about this?
>>
>>
>> I think support for a field with multiple types in its field-type
>> attribute should not be required. But maybe it makes sense to specify
>> the syntax as a comma separated list of type names in case a JDO
>> implementation does support this feature.
>>
>> Regards Michael
>>
>>>
>>> Craig
>>>
>>> On Dec 21, 2005, at 12:11 AM, Andy Jefferson wrote:
>>>
>>>> Hi Craig,
>>>>
>>>>> This proposal would allow more specific field type to be specified at
>>>>> deployment time compared to compile time. For example, a field of
>>>>> type Object could be specified in the jdo metadata as containing only
>>>>> instances of type SimpleClass.
>>>>
>>>>
>>>>
>>>> I don't read the proposal as saying that the user should specify the
>>>> type(s) as comma-separated if they want a field declared as Object
>>>> to store class A or class B or class C. What does the user do when
>>>> they have a field declared as Object and want to do this ?
>>>>
>>>>
>>>> --
>>>> Andy
>>>
>>>
>>>
>>> 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
>>
>
> 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