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 <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]>:Hello All Firstly please note my email address is [EMAIL PROTECTED] 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:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
