Re: Persistent Interfaces in JDO 2.0

[Craig L Russell <Cr...@Sun.COM>]

Hi Robin,

On Jul 20, 2006, at 5:36 AM, Robin M. Roos wrote:

> Hello All
>
> Firstly please note my email address is robin@roos.uk.net and I no
> longer see traffic on the JDO 2.0 Expert Group mailing list.

I assume that this is intentional. As you know, you are more than  
welcome to subscribe to the expert group mail list.
>
> I was discussing JDO 2.0 with a colleague who wants to represent
> collection-based relationships between persistent interfaces.  He
> was confused by the spec's requirement for get/set is/set methods
> to support persistent properties, and I was confused too until I
> vuaguely rememberd Craig and me taking opposing sides on what a
> persistent interface actually represents.
>
> My view was that a persistent interface represented a collection
> of persistent fields which were provided by all
> persistence-capable implementing classes, with field names in the
> interface mapped to field names in each persistent class.  This
> scheme allowed JDOQL to navigate through interface types, without
> requiring any specific method signatures in the interface (it
> might be a marker interface) and without requiring identical field
> names in each implementing class.

This is supported by the JDO 2.0 spec.
>
> I understood Craig's view was that a persistent interface was
> something which could be instantiated on demand by the JDO
> implementation without a developer-provided concrete
> implementation class.

This is also supported by the JDO 2.0 spec.
>
> I thought we compromised on a best-of-both-worlds basis.  But I
> now see that persistent interfaces must define get/set is/set
> methods.

This is the way that you map properties of an interface to fields in  
the persistence-capable classes that implement the interface.

> How then do we accommodate a collection relationship
> without exposing the Collection instance and breaking
> encapsulation?

We have never allowed hiding Collection instances from the  
persistence manager and persistence-capable class. That's how to- 
many  relationships are mapped.

> I might want an interface with methods
> addEmployee(), removeEmployee(), and employees():Iterator.  In
> JDOQL I would like to be able to use "contains" semantics against
> any persistent class which implements this persistent interface.
> If we could do this, then we could type more of the domain model
> using interfaces instead of abstract classes.  The application
> domain is financial trading, but I would have thought this
> capability would be streets ahead of anything planned by the JPA.

The issue for me isn't as much defining whether "contains" is  
supported; it is. The issue is about mapping relationships of  
interface types. So we should probably be more specific about the  
query that is of interest.

Let's say you have a persistent interface Instrument that has  
properties Symbol and LastQuote. There are two persistent classes  
that implement this interface: Stock and Bond. Each of Stock and Bond  
is mapped to the database in separate tables, and maps the persistent  
properties to columns.

You should be able to write a query like the following:

SELECT this FROM Instrument WHERE LastQuote < 100

You would get back a List of Instrument.

It's a bit trickier to establish relationships to Instrument from  
persistent classes, but this is primarily because of mapping, not  
interfaces. There is no standard way to map interface relationships  
to a relational database that don't have a common base class.

So let's say you have a persistence-capable class Portfolio that has  
a Collection of Holding. A Holding contains a reference to Instrument  
along with acquisition date and cost. If the classes that implement  
Instrument have no common base class and the classes are in multiple  
tables with no relationships among the tables, then there is no  
shared key to be used to join the tables. But let's say the mapping  
issue is solved. Then, you can use the following query:

SELECT this FROM Portfolio WHERE holdings.contains(holding) AND  
holding.instrument.lastQuote > 100

>
> I'm appending a brief excerpt from the JDO 2.0 spec regarding the
> interface element for easy reference.
>
> Please confirm whether or not what I want to achieve is supported
> by JDO 2.0 (I now believe it is not supported).

Please review the above to see if it's what you're looking for. And  
please feel free to add more concrete examples if needed.

> Additionally are
> there any plans for a maintenance revision which might add support
> for such a capability?  Personally I would like to see the
> newInstance() capability deprecated for persistent interfaces, but
> that's just me and I could never see its value.  In reality we
> would have to find a way of supporting both.
>
> I hope you are all well.

Speaking for myself, I'm fine.

Regards,

Craig
>
> Kind regards, Robin.
>
>
>
>
> JDO 2.0, February 28, 2006 p217:
>
> ELEMENT interface
> The interface element declares a persistence-capable interface.
> Instances of a vendorspecific type that implement this interface
> can be created using the newInstance(Class persistenceCapable)
> method in PersistenceManager, and these instances may be made
> persistent.
>
> The JDO implementation must maintain an extent for persistent
> instances of persistencecapable classes that implement this
> interface.
>
> The requires-extent attribute is optional. If set to “false”, the
> JDO implementation does not need to support extents of
> factory-made persistent instances. It defaults to “true”.
>
> The attribute name is required, and is the name of the interface.
> The attribute table is optional, and is the name of the table to
> be used to store persistent instances of this interface.
>
> The detachable attribute specifies whether persistent instances of
> this interface can be detached from the persistence context and
> later attached to the same or a different persistence context. The
> default is false.
>
> Persistent fields declared in the interface are defined as those
> that have both a get and a set method or both an is and a set
> method, named according to the JavaBeans naming conventions, and
> of a type supported as a persistent type.
>
> The implementing class will provide a suitable implementation for
> all property access methods and will throw JDOUserException for
> all other methods of the interface.
>
> This element might contain property elements to specify the
> mapping to relational columns.
>
> Interface inheritance is supported.

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!