Menu
Login Signup My Profile My Threads About the site
JDO 2.0: Lot's of changes discussed at the kickoff meeting

JDO 2.0: Lot's of changes discussed at the kickoff meeting


August 2003

Discuss this Article


Introduction

When you think of a JCP meeting about a JSR what do you envision? Many people on the outside probably feel like the JCP is a mysterious secret society. Vendors meet together and "plot" the course of a specification. We, the users, never get to see what is going on behind the scenes. We are sitting there with our fingers crossed, hoping that at the end of the long process, the expert group did the Right Thing (tm). Sun keeps changing the JCP process, trying to make it more and more open, but still. We want more don't we?

Well, I want to tell you about the JDO 2.0 kickoff meeting that I was fortunate to be part of last week. Since it wasn't an official JSR meeting (first we need a JSR to be accepted), everything said was public. This is very significant. Noone could hide behind the process, and everything was out there. With all of that, working groups with competing vendors got together over the 3 day meeting to work on things. Vendors were discussing what they did right now, and what they were planning to do in the future. I probably learnt much about the different JDO vendor products just via this information alone.

Let's talk a little about what went on at the meeting. First of all, SolarMetric kindly sponsored the event, and people from europe and beyond made it over. We had vendors like Solarmetric, LIBeLIS, POET, Hemisphere (JDOGenie), Progress (ObjectStore), Versant, and a couple of small companies you may know: Oracle and SAP. Along with vendors, we also had JDO experts like Robin Roos and David Ezzio, and Wes Biggs represented the open source world (he is on the XORM team). I would have loved to see Gavin King (Hibernate) present, and he has been approached, so hopefully he will be a part of this some time soon. It was great to see a mix of vendors, and "users" of the technology. The debate was very focused on what is the right thing for the developer, rather than haggling on innards for the vendors (should I be surprised?).

The three days were spent brainstorming on what JDO 2.0 should be all about, and getting into details on some of the technology that people want to put into it. People brought their JDO 2.0 wishlist, especially Robin who had put in a lot of work, ending up with a document the size of the Iraqi dossier :) This document was used as a reference throughout the discussions. We were all glad that Robin had put that much thought into the topics.

We first discussed what we wanted JDO 2.0 to be about at a high level, and seemed to come up with:

  • Standardize support of RDBMS: Users want the O/R mapping spec'd out in JDO. JDO/R will be created that will specify an O/R mapping layer.
  • Improve core areas like relationship management, and enhanced queries (better JDOQL, and SQL support)
  • Broaden the range of implementations: Address the 1.0 limitations of requiring binary compatibility, and that only classes, not interfaces, can be presistent.
  • Disconnected/Detached operation: Allow the user to detach the JDO persistence capable objects, and later re-attach them.
  • Align even stronger with the rest of J2EE (e.g. servlets and EJB)
  • Ease of use: API changes, metadata, and more.
This is the tip of the ice-berg though. There were a lot of really cool features talked about that don't seem apparant from those on the list above, but take a look through those and see how much JDO is willing to adapt in 2.0. Ok, for the rest of this report I will talk about items that were discussed by topic:
  • More flexible with respect to other JDO implementations: allow for reflection based approaches
  • JDO/R: metadata, inheritence, managed relationships / cascade delete
  • Queries: JDOQL updates, Named Queries, SQL standardization
  • Detach/Attach
  • Miscellaneous

Other JDO implementations


After we had gone through introductions, created the high level objectives, etc, Craig Russell (the spec lead from Sun) put down the first proposal.  He proposed that JDO allow interfaces to be used as well as classes, and that vendors could use dynamic proxies (or something) to create a PersistentCapable class that could be used just like any other JDO class.  This would allow you to model some, or all of your domain model as interfaces, and wouldn't seem to imply any real changes to the JDO apis, and just some new metadata to be added.  This also led to talking about allowing different implementations of JDO that were free to use reflection-based technology, AOP based, etc. There was rejoicing :)





JDO/R



The bulk of the day was then taken up with JDO/R discussions.  The room worked on the metadata that specified the O/R mapping features.  Since a lot of the vendors support O/R already, so this wasn't a new item for them... and it was just a case of merging ideas.  After a lot of work, a sub-group was created which has the mission of coming up with a first pass of XML schema.  This group did get together, at night (probably over a couple of beers).  There were four vendors on this sub-commitee, and they all said they were really impressed that everyone worked in the same direction, and got things done.  Robin Roos showed up the next day with an XML schema modelling tool on his computer screen, with a first pass of the actual schema.


Information on JDO/R inheritence, managed relationships, cascade-delete, and SQL query integration was also discussed.  Imagine being able to do the following in a standard way:



Query q = pm.newQuery("javax.jdo.SQL", "SELECT x, y, z FROM person WHERE name LIKE '%Beckham'");

Query q = pm.newQuery("javax.jdo.SQL", "CALL GET_BECKHAMS");




As long as you follow a few rules, (like having the primary key in the select clause) then you will be able to pass through SQL that your DBA is free to play with and tune.


SQL isn't the only possible language addition.  You can imagine support for other languages like OQL, VQL (Versant), etc.


If you were getting push back from your DBAs, who were saying "I can't use JDO because I can't tune the SQL", you now have a way to respond: "Give me any SQL you want my friend!".




Queries



There was much debate on the query side of JDO.  Michael Bouschen and David Ezzio produced a document discussing "Projections and Aggregates", "JDOQL and Interfaces", "New String Methods in JDOQL", and "Addition of isEmpty() method to JDOQL".  We all started on the first page, but (as is common) hit various tangents.  Aggregates were something that everyone wanted added in JDO 2.  It will be nice to be able to things like setResult("count(this)") which would be able to deduce that you want an Integer back.  You should also be able to do setGroupBy("x,y,.."). However, what should be returned from that bad boy?  After discussion, people reasoned that we need to support something simple that always behaves the same for tools (e.g. a Collection of Object[]), but also a nice container for programmers to use (e.g. your own class that will be populated with the return data).  This way you could use syntax like "count(this) as linecount", and 'linecount' could be set in your JavaBean.... or something like that.  We also got into whether users would want to have an executeUnique(...) kind of method, that is meant to return "one" thing to you.  The reason is purely laziness.  Do we want to get a collection and then .iterator().next() each time?  Since the execute(...) method has many overloaded varients, this isn't taken lightly, so talk changed to being able to do:


query.setParameter[s](...)
query.execute() / query.executeUnique() / ...



This way, if more execute methods are added, there wouldn't have to be 6 new methods.  Issues of multi-threading came up, but it looks like setParameter() could win the day.




JDOQL should be extended so that we can navigate through interfaces.  Currently JDOQL cannot traverse relationships which are methods of an interface, so developers resort to hacks such as using abstract classes instead of interfaces.



There are a bunch of String based methods that merit addition to JDOQL, such as name.matches("some expression"), upper/lower, substring()/indexOf(), length(). and more.  There isn't a way to directly filter based on a collection being empty, so adding an isEmpty() method would be great.





Named Queries



Named queries was another item that people were looking forward to having.  In code, you could executeNamedQuery("FIND_TOP_TEN"), and have the query itself be externalized (in an xml file, properties file, in JNDI, etc).  Eric Samson (of LIBeLIS) talked about named queries, and the idea of use cases



Use Cases



This is a fairly open idea right now, however the idea is that a developer can setup different "use cases", which can encapsulate performance characteristics. For example, if you are in one use case, use a particular fetch group (as you know that in this case you will need X, Y, and Z), a certain locking strategy, etc.  This could be really powerful, so look out for this concept in the future!



Deletion by Query



How do you delete "stuff" in JDO at the moment?  Chances are you run a query that finds the items you want to delete, and then pass them to deletePersistentAll().  This works, but has the side-effect of instantiating each object.  This is a waste of efford when you just want to nuke the guys!
Something like a query.deleteByQuery(...) semantic will be added to help fix this.




It is interesting to think about what should be part and parcel of JDOQL.  Can we come up with something that is implementable in all datastores? (e.g. OODBMS).  As items were mentioned, the OODB guys would let us know what they though.  They weren't trying to veto anything!  JDOQL will be a much different beast in JDO 2.0, and along with the standardized support for SQL, you should be able to breathe the air of freedom, instead of trying workarounds, or using JDO extensions to get the work done. (Will EJB-QL follow this lead?)




Detach/Attach || Disconnect/Reconnect



Wow this was a hot topic.  The idea is that users want to be able to use JDO to get data from the cache/db, disconnect from the system (PersistenceManager), maybe update some data, and reattach that object to the PM.  Sounds easy doesn't it?  Well it isn't :)  Before we even got into how best to do this, some people
weren't sure that we should offer this at all.  For them, it would promote some bad design, almost akin to having Entity Beans abused.  It was so easy to just create an Entity Bean that people did it without thinking about the performance costs of talking to her from across a barrier (VM/network).  Do we want to give developers enough rope to hang themselves?  Philosophically, should an expert group / spec, be thinking about those things too much, or should that be left up to the users?  Interesting.  After that discussion, we got into the meat of how this could be done, and some rules were worked on the times when this could be done. A big question was whether or not the detached objects needed to be lightly managed or not.  What kind of information would need to come back to the PM from the detached object in order to reattach it?  The end result was that we needed the Object ID, and some kind of context object (which may just have version information in it, but more likely more state information). This feature will piggy back on the fetch group / use case feature, where you will be able to tell the system what cut of the object graph you want when you detach.





Miscellaneous



There were a lot of other features discussed at the meeting.  Here is a subset of the items discussed, just to keep you in the loop.
Again, Robin was the agent of change for most of these.




Changes to Spec Wording



There was a lot of talk about the Extent interface. People don't like the second subclass method param, so there was talk of having a getExtent(Class) method.  At one point a train of thought ended in the idea that there would be a way to get rid of the idea of an Extent, so although it will probably be present for backwards compatibility reasons, JDO 2.0 may not be talking too much about Extents! 
Some small points were discussed such as having the requirement that ObjectIds are automatically encoded for use on the web.





Changes to API


 It looked like the current InstanceCallbacks interface will be broken down into sub-interfaces such as DeleteCallback, LoadCallback, StoreCallback, ClearCallback, etc (or maybe an event based system).  This would allow developers to implement just ONE of these interfaces, and therefore won't have to implement the rest, some of which can be quite expensive (e.g. preDelete() notifications require persistent instances to be instantiated prior to deletion).  JDOHelper was touched upon throughout the changes discussed.  One of the simple additions will be to allow a nice bootstrapping mechanism via methods such as JDOHelper.getPersistenceManagerFactory(File f || String resourceName || InputStream i || ...).  The Transaction interface will also be given getRollbackOnly(), and setRollbackOnly().  With this addition, different areas will result in calls of setRollbackOnly().




I want my data store connection!



What if you want to use JDO, and it works for 99% of your use cases, but on that 1% you really wish you could just get the database connection, and run some wacky query, or set some Oracle Driver specific info.  Well, you will be able to.  It looks like there will be a backdoor that will enable you to ask JDO for the database connection and/or datasource object.  This way you can take part in the same transaction and be happy as larry.  There will also probably be some eviction model that will let you evict objects from the cache.




A lot, lot more



Well, this report is getting kinda long, and although I haven't gone through all of the ideas that were expressed in the meeting, I hope that you get a feel for what is being talked about, and what will be part of JDO 2.0.  If you have ideas of your own please mention them on TheServerSide, send them to Craig, or wait until the JSR has been created and send to that list.  It is going to be a great ride, and I am hoping that JDO 2.0 can live up to what I saw at this meeting.  A lot of people getting together as a team, and creating some great technology.  Join us.






Author



Dion Almaer (dion@theserverside.com) is Chief Architect of TheServerSide.com, a service of The Middleware Company (www.middleware-company.com), one of the nation's leading training companies in EJB/J2EE and B2B technology training. He is also part of the JDO 2.0 expert group.








PRINTER FRIENDLY VERSION