db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wes Biggs <...@tralfamadore.com>
Subject Re: updates to tck11 project
Date Sat, 02 Apr 2005 19:35:27 GMT
It seems to me that the spec was purposefully quite vague in this 
regard, and my reading was that, sure, you could have a field declared 
as type Object, but that really implied very little about what could be 
stored (mapped) into it.

My take on the current spec is that the mapping might actually restrict 
the field to only one type (or hierarchy), and throw ClassCastException 
or something similar for other types.

As Craig says, this is a mapping issue -- it's possible that my object 
model is defined to take Object, but my data model had as hard foreign 
key constraint that the field actually has to be an Employee.  In this 
scenario I think the current spec is good.  There are plenty of 
legitimate reasons (even disregarding Java5 generics) you might have a 
field of type Object but know as a programmer or deployer that it will 
only actually store an Employee reference.

Now, if we had a way to delineate exactly what types are defined as 
mappable for a field, it might be reasonable for the ORM part of the TCK 
to exercise these types (or one of them).  Beyond that I don't think 
this should be part of the TCK.


Patrick Linskey wrote:

> I do not think that the JDO spec should require that non-PC, 
> non-primitive Object fields be Serializable. I am fine with the TCK 
> not testing non-PC, non-primitive, non-Serializable Object fields, but 
> this limitation should certainly not be put into the spec.
> I'm ok with the spec requiring that non-PC, non-primivite, 
> Serializable fields must be storable by an impl, but not with the 
> converse.

View raw message