db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: Persistent Interfaces in JDO 2.0
Date Thu, 20 Jul 2006 15:59:18 GMT
Hi Robin,

On Jul 20, 2006, at 6:42 AM, Robin M. Roos wrote:

> Hi Eric et. al.
>
> If you look at the spec section 18.10 the "implements" element is
> used to notate that a (potentially concrete) persistent class
> implements a persistent interface.  That means I can navigate to
> or query the Interface type and arrive at the persistent instance.
>  This is definitely a concrete developer-provided instance.

Not necessarily. It could be a developer- or implementation-provided  
instance.
>
> Then from Section 18.21 the "implements" element contains
> "property" elements which are used to map persistent fields of the
> concrete class to the, if I may use the word here, "abstract"
> properties of the interface.
>
> [I actually believe the "property" element in this context, within
> "implements" should be a simpler XML element which maps the name
> from the interface to a fully defined property in this
> persistence-capable, but the DTD reuses the same property element
> here.  This potentially stops one class from implementing two
> interfaces and mapping the "description" property of each of them
> to the same persistent field.  It would have to define the field
> twice if "description" was an (abstract) property in both
> interfaces.]

Java has this same restriction. A class that implements multiple  
interfaces must have identical implementations for methods from the  
multiple interfaces that have the same signature. There's no way to  
disambiguate the methods of one interface from the others. Do other  
languages allow different behavior?
>
> The big concern I have is the requirement for the interface to
> provide methods at all.  Properties can be of many types, and we
> could insist on get/set (default) is/set (boolean)
> add/remove/iterator (List/Collection/Set) put/get (Map) etc., but
> it is more flexible and not more dangerous for there to be no
> requirement for any specific method convention.  The developer
> will put appropriate methods on the interface to suit his object
> model, but JDO does not need to know what they are in order to
> satisfy its obligations to the object model.

That's true, and there is no restriction placed on non-persistent  
methods of persistent interfaces. Just don't declare them or use them  
in queries. But if persistent properties are used in queries, the  
implementation needs to know how to map them to the underlying query  
language. Since we don't know what add/remove/iterator are supposed  
to do, they cannot be used in queries.
>
> The extreme case is a marker interface called Product.  You could
> navigate an association to a Product.

Let's get specific about how to map the association. Any suggestions?

> You could iterate the Extent
> of Product.  You could have JDOQL queries which navigate to
> Product and through its (abstract) properties as required.  But if
> the Product interface has no methods

As mentioned above, you can have business methods that are not the  
concern of the persistence layer but are only in the domain model. In  
this case, it doesn't make sense for the JDO implementation to create  
an implementation of the persistent interface (you knew that, but I  
thought it worth mentioning). That's why we also support persistent  
abstract classes, in which the business behavior can be implemented  
solely using persistent properties.

> you must cast the result to a
> concrete class before you can really use the (concrete
> implementing type) Product instance you get back.  This is an
> extreme example, but I just want to illustrate that JDO should not
> force a requirement on the object model which is not necessary for
> persistence purposes.

Agree.
>
> Naturally this perspective is different to Craig's use-case of
> having the JDO 2.0 implementation perform the function of
> "persistent dynamic proxy" factory.  I had thought we'd
> successfully merged these two use-cases.

Me too.

Craig
>
> Kind regards, Robin.
>
>
>
> On Thu Jul 20 06:07:05 PDT 2006, Erik Bengtson <erik@jpox.org>
> wrote:
>
>> Robin,
>>
>> I understand that you want to be able to allow user providing
>> their own concrete
>> classes. I'm not sure if this is spec compliant, but JPOX for
>> instance supports
>> user and JDO vendor concrete implementations. That means users
>> are not obliged
>> to invoke pm.newInstance() if they already have their own class,
>> however JPOX
>> requires that the user concrete class to implement
>> PersistenceCapable.
>>
>> Regards,
>>
>>
>> Quoting "Robin M. Roos" <robin@roos.uk.net>:
>>
>>> 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 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.
>>>
>>> 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.
>>>
>>> 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.  How then do we accommodate a collection relationship
>>> without exposing the Collection instance and breaking
>>> encapsulation?  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.
>>>
>>> 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).  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.
>>>
>>> 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!


Mime
View raw message