Need attribute on field element for type

• Key: JDO-204
• Type: Bug
• Status: Resolved
• Resolution: Fixed
• Priority: Major
• Assignee: Craig Russell
• Reporter: Michelle Caisse
• Component/s: api2
• Fix Version/s: JDO 2 beta

Description

Need to supply instantiated type information for Object & Interface fields.

Comments

[Craig Russell]

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:

<!ATTLIST field field-type CDATA #IMPLIED>

[Craig Russell]

We already have:

<!ATTLIST collection element-type CDATA #IMPLIED>
<!ATTLIST map key-type CDATA #IMPLIED>
<!ATTLIST map value-type CDATA #IMPLIED>
<!ATTLIST array element-type CDATA #IMPLIED> (recently added)

The proposal would have the same semantics as the element-type, key-type, and value-type of the multi-valued field types collection, map, and array.

[Andy Jefferson]

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.

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.

[Michael Bouschen]

I understand the scenario that the user wants to store instances of different PC types in the 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.

[Craig Russell]

I understand that some implementations have the ability to store completely different classes in a persistent field. But there is currently no standard way to describe how this is done. For example, in JDO1 TCK we had a field of Object and stored String and Long in the field in different instances. And if you serialize the contents of the field, there is no issue. But now we allow the user to specify the mapping for embedded and referenced storage. And there is no standard way for the user to tell the implementation how to store these. You would at least need some discriminator column to store the class of the instance.

Without having a standard way to describe the storage of heterogeneous instances, I'm reluctant to go too far in standardizing the classes that can be stored in the field. But this is different from the proposal, which is to allow overriding of the compiled field type at deployment time, for example to specify that even though the object model says that there is an Object stored in a field, the only class that can be stored there is a SimpleClass.

That said, I don't object to using the field-type to name a list of classes that can be stored, and using the <extension> metadata to describe in more detail how the storage is to be done.

[Craig Russell]

The field-type attribute has been added to the field element in the jdo metadata. This will allow specifying the specific field type needed for the TCK.