|
Home > Archive > Apache JDO Project > June 2005 > updates to tck11 project
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
updates to tck11 project
|
|
| Michelle Caisse 2005-06-06, 7:48 am |
| 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
| |
|
| 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
| |
| Matthew T. Adams 2005-06-06, 7:48 am |
| 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
>
>
| |
| erik@jpox.org 2005-06-06, 7:48 am |
| 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
>
>
>
>
| |
| Matthew T. Adams 2005-06-06, 7:48 am |
| 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>:
>
>type is Object
>about others?
>
>
>
>
| |
| Craig Russell 2005-06-06, 7:48 am |
| | |
|
| 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
>
>
>
>
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!
| |
|
| I'm okay with it; could we include in the spec that Object fields must
either implement Serializable or PC ?
Erik Bengtson=20
-----Original Message-----
From: eric@xcalia.com [mailto:eric@xcalia.com]=20
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]=20
Envoy=E9 : samedi 2 avril 2005 10:19
=C0 : 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=20
-----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=20
> require that your users make their Object-typed field instances=20
> serializable (section 6.4.3), since you are allowed to restrict the=20
> instances that can be stored in these cases. If they don't implement=20
> 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=20
> must be thrown at the time of any incorrect assignment.
>
> Portable JDO applications must not depend on whether these fields are=20
> treated as SCOs or FCOs.
> </quotation>
>
> --matthew
>
[vbcol=seagreen]
>
>
>
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 2005-06-06, 7:48 am |
| | |
| Craig Russell 2005-06-06, 7:48 am |
| | |
| Craig Russell 2005-06-06, 7:48 am |
| | |
| Patrick Linskey 2005-06-06, 7:48 am |
| | |
| Eric Samson 2005-06-06, 7:48 am |
| 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]=20
Envoy=E9 : samedi 2 avril 2005 10:19
=C0 : 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=20
-----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=20
> require that your users make their Object-typed field instances=20
> serializable (section 6.4.3), since you are allowed to restrict the=20
> instances that can be stored in these cases. If they don't implement=20
> 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=20
> must be thrown at the time of any incorrect assignment.
>
> Portable JDO applications must not depend on whether these fields are=20
> treated as SCOs or FCOs.
> </quotation>
>
> --matthew
>
[vbcol=seagreen]
>
>
>
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!
| |
| Wes Biggs 2005-06-06, 7:48 am |
| 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.
Wes
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.
>
| |
| Patrick Linskey 2005-06-06, 7:48 am |
| |
|
|
|
|