Hi Robin, On Jul 20, 2006, at 5:36 AM, Robin M. Roos wrote:
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 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:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
