Resend: Questions regarding persistent interfaces

[Leschke Scott-QA2775 <Sc...@motorola.com>]

 
I sent the following previously but received no response. I'm resending.

Scott Leschke

-----------------------------------------------

I have some questions regarding persistent interfaces.
 
1) If a class implements (in the Java sense via the 'implements'
clause), an interface that is declared persistent-capable in the
metadata, does the corresponding <class> element in the metadata also
required to have a corresponding <implements> element or is the element
implied by the Java structure? I think one would expect this but the
spec doesn't say explicitly.
 
2) If a class implements a persistent-capable interface, is there a
default mapping between the interface properties and class field names
(i.e. would a property named "modDate" of type java.util.Date map by
default to a field in the implementing class of the same name and type?
If not, why not?
 
3) Based on the spec, I guessing the answer to this is no but given a
persistent-capable interface, is there a way to specify that
implementation generated instances (i.e. pm.newInstance(interfaceName))
should not be allowed?
 
Regards,
 
Scott Leschke

RE: Resend: Questions regarding persistent interfaces

[Matthew Adams <ma...@xcalia.com>]

Hi Scott,

See responses inline... 

>1) If a class implements (in the Java sense via the 'implements'
>clause), an interface that is declared persistent-capable in the
>metadata, does the corresponding <class> element in the metadata also
>required to have a corresponding <implements> element or is the element
>implied by the Java structure? I think one would expect this but the
>spec doesn't say explicitly.
> 
You're right.  The spec doesn't say explicitly.  It is clear from the
Java class definition and persistence metadata that a
persistence-capable (PC) Java class that implements (in the Java
language sense "implements") a PC interface, so it should not be
explicitly required in the metadata.  Since the specification is silent
about this, you're left to the JDO implementation's default.  The JDO
2.0 metadata schema (jdo.xsd) declares the <implements> element to be
optional, so it is legal according to the schema, and it is not illegal
according to the specification document.  We will discuss making this
default explicit in the specification.  I don't think it's too much of a
stretch.

>2) If a class implements a persistent-capable interface, is there a
>default mapping between the interface properties and class field names
>(i.e. would a property named "modDate" of type java.util.Date map by
>default to a field in the implementing class of the same name and type?
>If not, why not?
>
I'm not sure what you mean by a "mapping between the interface
properties and class field names".  This is evident from the Java
definitions of the class that implements the interface.

I'll assume that the class that implements the PC interface is PC itself
and authored by the user.  In that case, regardless of the properties of
the interface, I would expect that the implementation should use the
mapping of the underlying PC class and ignore any <property> elements
under <interface>, but the specification doesn't state this explicitly.
Perhaps it should be explicit here -- we'll discuss.

If the class is implementation-generated via
pm.newInstance(MyPCInterface.class), then the specification says that
the persistent fields declared in the interface are those according to
the JavaBeans conventions.  In that case, I would say that the default
mappings are implicit:  they are the same as for those of PC classes
that would have fields of the same names and types of the properties of
the PC interface.  Again, this is not explicit in the spec, and could be
made so.  We'll discuss.

>3) Based on the spec, I guessing the answer to this is no but given a
>persistent-capable interface, is there a way to specify that
>implementation generated instances (i.e. pm.newInstance(interfaceName))
>should not be allowed?
> 
This is not standardized in JDO 2.0.  An implementation could support it
via the extension mechanism in the metadata.  An enhancement to the
standard metadata could be made so that if a call to
pm.newInstance(MyPCInterface.class) was made, a JDOUserException could
be thrown.  We would have to add metadata to the <interface> element
(probably by adding an attribute) that would state that
implementation-generated implementations of the interface are
disallowed.  We'll discuss.

Good questions, Scott, and sorry for not responding sooner.  We'll put
these on the agenda for tomorrow's conference call, which you are
welcome to attend!

-matthew

RE: Resend: Questions regarding persistent interfaces

[Matthew Adams <ma...@xcalia.com>]

Hi Scott,

Inline...

>-----Original Message-----
>From: Matthew Adams 
>Sent: Thursday, February 22, 2007 10:58 AM
>To: 'jdo-user@db.apache.org'
>Subject: RE: Resend: Questions regarding persistent interfaces
>
...
>>2) If a class implements a persistent-capable interface, is there a
>>default mapping between the interface properties and class field names
>>(i.e. would a property named "modDate" of type java.util.Date map by
>>default to a field in the implementing class of the same name 
>and type?
>>If not, why not?
>>
>I'm not sure what you mean by a "mapping between the interface 
>properties and class field names".  This is evident from the 
>Java definitions of the class that implements the interface.
>
Sorry, my misunderstanding there (I was focused on the OR mapping
metadata, not the property-field mapping).  The mapping between the
interface properties and class fields is normally achieved via the
"field-name" attribute on the <property> element in the <implements>
element, and it's probable that what you describe is achievable by
default.

We are proposing a spec change to address & clarify this and will
discuss on tomorrow's call.

-matthew