Hi Michael, > 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.
OK, that's one way of approaching it and I've no real issue with doing that, *but* consideration needs to be made to what people did in JDO1 when they wanted 2 or more PC types to be storeable in a Collection - they used element-type="Object" (which is the default for "element-type"). If they specify element-type="Object" now what does it mean and what does the implementation do ? It can't mean that the elements can be PC types since in that case they should specify multiple element type comma-separated values in that case. Maybe a JDOUserException ? > 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. Yes, having it optional to support multiple element-type (or key-type, value-type) classes in a Collection/Map/Array would have my support. That would however beg the question whether having a Collection with an element using subclass-table is also optional. The issues are the same in terms of implementation of those features - multiple FKs from a join table relation, and joining across multiple element tables. -- Andy
