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: Issue 139: Add field-type attribute to field element
Date Tue, 15 Nov 2005 23:24:04 GMT
Hi Andy,

>Hi Craig,
>
>  
>
>>It sounds like you are thinking that you would like two different  
>>attributes, one for "element-type" and another for "implementation- 
>>type". Can you explain what the difference is? I only see the need  
>>for one value here: the type that can be stored in the field,  
>>element, key, or value.
>>    
>>
>
>Lets take the example of Collection. The element-type will be java.lang.Object
>(or the interface type when using interfaces). The element-implementation-type
>will be the actual PC types stored there. Notice that I said types (plural). The
>user wants to store more than one PC type in the same collection, so they declare
>it with element-type as Object. The point of then defining which PC types are
>valid is to allow the JDO impl to manage the persistence of this collection.
>  
>
I understand your scenario that the user wants to store instances of 
different PC types in this collection. This means even with JDK 5 you 
need to define the field with Collection<Object> in the Java source. The 
JDO metadata can be more specific when specifying the element-type. All 
you need is the possibility  to specify more than just one element-type. 
However, I think this can be done using the existing element-type, so I 
do not see the need for another metadata element such as 
element-implementation-type.

I think the spec could allow that the element-type value is a list of 
type names, but I'm not sure whether we should require that every JDO 
implementation needs to support multiple element-types. Maybe this 
should be an optional feature. The same holds true for multiple type 
names in field-type.

Regards Michael

>The same applies to a field of type java.lang.Object (or an interface). The user
>wants to store some PC type there. In one object it may be a PC type A. In
>another object it may be a PC type B. The implementation-type (or field-type in
>your case) will be the possible types that can be stored.
>
>In the case of interfaces, we clearly have the "implements" information to
>provide this implementation definition, but the benefit of adding an attribute to
>each field/collection/array etc is that the user can then restrict each field to
>a subset of the possible implementations.
>
>The TCK, as you currently have it, only typically has one "implementation type".
>The real world has many implementation types and the user needs the flexibility
>to select from them.
>
>Now that I've mentioned that I have in mind plurals, maybe it would be better to
>use XML properly and add a subelement to store the names of these PC
>implementation types. It would work with an attribute, storing a comma-separated
>list of names, but then XML allows it to be done better than that.
>
>
>Hope thats clearer.
>
>--
>Andy
>  
>


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