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
|