db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Linskey <...@solarmetric.com>
Subject Re: updates to tck11 project
Date Sat, 02 Apr 2005 17:42:21 GMT
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.

-Patrick

On Apr 2, 2005, at 12:10 PM, Craig Russell wrote:

> Hi Erik,
>
> I've logged this as Issue 98.
>
> On Apr 2, 2005, at 1:34 AM, erik@jpox.org wrote:
>
>> I'm okay with it; could we include in the spec that Object fields 
>> must
>> either implement Serializable or PC ?
>
> This probably goes too far in requiring implementations to support 
> arbitrary Objects that implement PC. The issue is that PC isn't quite 
> strong enough as a restriction. For example, an implementation might 
> require, during mapping, for any Object assigned to the field to 
> implement an interface that it knows how to map to the datastore. 
> This is a limitation of the mapping that isn't expressed in the 
> object model.
>
> I'm struggling just a bit with how to word this in the 
> specification...
>
> An alternative is to remove these cases from the TCK but that leaves 
> the spec a bit untested (untestable?).
>
> Craig
>
>>
>> Erik Bengtson
>>
>> -----Original Message-----
>> From: eric@xcalia.com [mailto:eric@xcalia.com]
>> Sent: Saturday, April 02, 2005 11:05 AM
>> To: erik@jpox.org; jdo-dev@db.apache.org; 'JDO Expert Group'
>> Subject: RE: updates to tck11 project
>>
>> Erik
>>
>> In LiDO when an attribute is a java.lang.Object we don't impose the
>> referenced object to be serializable if it is a PC. But if it is not 
>> a
>> PC it
>> must be Serializable, as for embedded objects.
>>
>> Best Regards
>> .:
>> Eric Samson, xcalia
>>
>> -----Message d'origine-----
>> De : erik@jpox.org [mailto:erik@jpox.org]
>> Envoyé : samedi 2 avril 2005 10:19
>> À : jdo-dev@db.apache.org; 'JDO Expert Group'
>> Objet : RE: updates to tck11 project
>>
>> If all implementations require that Object type fields to implement
>> Serializable, in the JDO spec we should mention it and in the TCK
>> classes
>> should implement Serializable.
>>
>> The only thing I don't want is to have to hack the TCK in order to 
>> pass
>> the
>> tests.
>>
>> Erik Bengtson
>>
>> -----Original Message-----
>> From: Craig Russell [mailto:Craig.Russell@Sun.COM]
>> Sent: Saturday, April 02, 2005 2:33 AM
>> To: JDO Expert Group; jdo-dev@db.apache.org
>> Subject: Re: updates to tck11 project
>>
>> Hi,
>>
>> I'm not sure what the question is here. Is it whether the TCK 
>> correctly
>> tests the Object field type?
>>
>> Craig
>>
>> On Apr 1, 2005, at 1:39 PM, Matthew T. Adams wrote:
>>
>>> From a specification standpoint (I just checked), I guess you can
>>> require that your users make their Object-typed field instances
>>> serializable (section 6.4.3), since you are allowed to restrict the
>>> instances that can be stored in these cases.  If they don't 
>>> implement
>>> Serializable, you can throw a ClassCastException and still be
>> compliant
>>> with the spec.
>>>
>>> <quotation>
>>> Object Class type
>>> JDO implementations must support fields of Object class type as 
>>> FCOs.
>>> The implementation
>>> is permitted, but is not required, to allow any class to be assigned
>> to
>>> the field. If an implementation
>>> restricts instances to be assigned to the field, a 
>>> ClassCastException
>>> must be thrown at the time of any incorrect assignment.
>>>
>>> Portable JDO applications must not depend on whether these fields 
>>> are
>>> treated as SCOs or FCOs.
>>> </quotation>
>>>
>>> --matthew
>>>
>>>> -----Original Message-----
>>>> From: erik@jpox.org [mailto:erik@jpox.org]
>>>> Sent: Friday, April 01, 2005 12:47 PM
>>>> To: matthew.adams@xcalia.com
>>>> Cc: jdo-dev@db.apache.org; jdo-experts-ext@sun.com
>>>> Subject: RE: updates to tck11 project
>>>>
>>>>
>>>> I ask if a JDO implementation, in order to support 
>>>> java.lang.Object,
>>>> can require from the classes to be persisted to implement
>>>> Serializable.
>>>>
>>>> Are there any requirements from LIDO to store Object types?
>>>>
>>>> Quoting "Matthew T. Adams" <matthew.adams@xcalia.com>:
>>>>
>>>>> LiDO supports it.  Any instance stored in the field whose
>>>> type is Object
>>>>> must be either a PC, a PI, or custom-mapped.
>>>>>
>>>>> --matthew
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: erik@jpox.org [mailto:erik@jpox.org]
>>>>>> Sent: Friday, April 01, 2005 11:09 AM
>>>>>> To: jdo-dev@db.apache.org
>>>>>> Cc: jdo-experts-ext@Sun.COM
>>>>>> Subject: RE: updates to tck11 project
>>>>>>
>>>>>>
>>>>>> I wonder if we require developers willing to store 
>>>>>> java.lang.Object
>>
>>>>>> implement Serializable interface. JPOX requires it, what
>>>> about others?
>>>>>>
>>>>>> Currently, the TCK does not implement Serializable.
>>>>>>
>>>>>>
>>>>>> Erik Bengtson
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Michelle Caisse [mailto:Michelle.Caisse@Sun.COM]
>>>>>> Sent: Friday, April 01, 2005 7:21 AM
>>>>>> To: jdo-dev@db.apache.org
>>>>>> Subject: updates to tck11 project
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I have made the following commits to tck11:
>>>>>>
>>>>>> -  Fixed problem with Oid classes reported by Erik
>>>>>> -  Fixed a couple of minor problems with maven.xml in the
>>>>>> runtck.single and enhance.*identity goals.
>>>>>>
>>>>>> -- Michelle
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>> 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!
>>
>>
>>
>>
>>
> 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!

-- 
Patrick Linskey
SolarMetric Inc.


Mime
View raw message