Mailing-List: contact jdo-user-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jdo-user@db.apache.org
Received-SPF: pass (herse.apache.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Resend: Questions regarding persistent interfaces
Date: Thu, 22 Feb 2007 19:57:40 +0100
Message-ID: <345CC4DC7C636849B221B217D34C31192FC96E@intranet.xcalia.net>
In-Reply-To: <84FF2D40FEDEB74A98203E6EA01A4E1C030AB44A@de01exm63.ds.mot.com>
Thread-Topic: Resend: Questions regarding persistent interfaces
Thread-Index: Acc6lQD6UuXZcb5SQ/6TQsdvZfZzdgbenoRAACZZDfAAAVffwA==
References: <84FF2D40FEDEB74A98203E6EA01A4E1C030AB44A@de01exm63.ds.mot.com>
From: "Matthew Adams" <matthew.adams@xcalia.com>
To: <jdo-user@db.apache.org>

Hi Scott,

See responses inline...=20

>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.
>=20
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?
>=20
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