Thursday November 18, 2004
Java
Intelligent data with Derby, JDO and JPOX... these three items give me something that I have wanted for a long time in my own personal Java apps.
Many times when crafting a Java app I've wanted to have an intelligent data store. Something that I can fire queries at and something that has persistence so that it is available the next time the app is run.
Well of course there are many ways to do this with vanilla Java, custom maps and collections, serialization, etc, etc. All very awkward, especially the data querying.
What I really wanted was a relational database type mechanism that I could throw objects at and then query later. However writing all the classes to wrap the SQL is a drag and specific to each object/table. Also for my sins in the past I had only really ever used Sybase which was far too heavy weight for my Java apps.
In my last job I did get to play with an embedded Java relational database called InstantDB which my last company, Lutris, originally bought and distributed with Enhydra. To make life easier talking to IDB (or any other RDBMS) Enhydra had a package called DODS (Data Object Design Studio). In essence you described some container objects and where they would live in a RDBMS, and DODS generated classes that hid the SQL. It was clunky but it kind of worked.
As I said I wanted to return to the RDBMS object persistence and do it in as a general way as possible. Since my days at Lutris there are some new technologies available that are worth looking at.
Instead of InstandDB a natural choice is Derby, a Java embedded (or standalone server) RDBMS (originally Cloudscape). My first impressions were, "this is really neat". So Derby gives me my data store.
Next is the convenient object to data store mechanism. Well this is where JDO (or Java Data Objects) comes. You have to do more than DODS because you have to generate your inital data objects yourself (the objects that will live in the RDBMS). JDO then "enhances" the classes files. This is the bit that I don't really like. Enhancing your data objects involves modifying the class files and inserting code into them. This all sounds dodgy to me but it works. DODS is different because it generates all the data objects and guts as Java source that then must be compiled.
Included with JDO is JDOQL (query language). This gives you a way of acquiring a collection of a single class of object using a query. The query can refer to the fields of the data object to narrow down the field of returned objects.
JPOX comes into this because it is an implementation of the JDO standard. And it also works with Derby! The two can hook up to provide a RDBMS backed JDO configuration.
After some days of head scratching last evening I finally cracked it. Now I have a simple person object that I cam insert into my data store. Then I cam query fields in my person object when I need to retrieve specifc objects.
When I get a chance I'm going to try something a little more ambitous. A good resource for JDO information is JDOCentral.
(2004-11-18 17:00:43.0)
Permalink
General
England's first snow of winter... well okay a light dusting.
The BBC make it all sound more glamorous. I had to photograph it because the kids won't believe me tomorrow morning. Well at least it made it as far south a North Herts and it is quite early (and quite rare) for the south east. I suspect this is all we will see this season.
Before anyone points out that this is nothing like real snow, I know, but here in the UK just the thought of snow sends people spinning in panic. I expect tomorrow the UK to be gridlocked with no roads or trains running.
(2004-11-18 16:20:14.0)
Permalink
General
So which planet is HP on? If they think they are in this universe they are clearly mistaken.
I know I probably shouldn't be doing this, I should just get on with my work but I've just read Martin Finks web page and it distracted me sufficiently that I'm here in my blog.
Darn it, just found this Get the Real Story about Solaris on x86 as well. Some real interesting "Facts" in here people.
For instance, "Fact 1" with regards to binary compatibility did we (Sun) ever say SPARC and x86 were binary compatible? Okay so I followed the [4] reference that HP have supplied. This eventually led me back to a Sun website and FAQ item #26. For starters they've referenced an Itanium item not a SPARC/Opteron item. What they really want is FAQ #25. Which does clearly state that SPARC and x86 are not binary compatible. So where's the sensationalism HP? All they have done is peddle the same facts that we've already given out.
As for endianess, where is the news here? From what I understand HP have got a bigger problem with customer systems and endianess. [In case some readers have forgotten, HP bought Compaq, who bought Digital, so it's really HP Tru64]
"Fact 2", proprietary Solaris? Is it any more proprietary than Windows, HP-UX and Tru64? I couldn't find the links on the HP web site that said their OSes were any more open source than Solaris. We also sell Linux and so does HP, everything HP levels at Sun can quite easily be levelled back at HP. No high ground.
"Fact 3", yes why would you mix the management of the two systems. Did HP miss the consolidation pitch that Sun gives? It's not the only pitch we give, it's just one of the many choices we give our customers.
And so on and so on. I could continue but I tire you the reader and myself the writer.
Lastly though I would like to thank Martin for acknowledging the launch of Solaris 10.
ps: Is Linux HP's dirty little secret? I notice in HP's 4th quarter results both HP-UX and Alpha get a mention, but not Windows, x86, Itanium, Opteron or Linux. Obviously these were not interesting enough for HP to mention.
(2004-11-18 06:45:53.0)
Permalink
