Hibernex

Hibernex is a proof of concept. It shows that you can automate the task of taking XML data and loading it into a database without any of the tedious programming like you have to do for a Torque mapping.

My original idea was that Hibernex would simply be a connector between Hibernate and XMLBeans, hence the name.

There is one glaring shortcoming which I am beginning to realize. That is, it assumes that working with data via RDBMS interfaces (SQL, Hibernate, etc.) is the most desirable route.

I am beginning to think this is not the case. If the data is coming in as XML, it should be manipulable and readable as XML. No reason to force the developer to jump through hoops. Hibernex in its current direction removes a few hoops, but it is still far from ideal.

Here is the overall direction I am going in:

1) First, trim down the steps to create a loader JAR from 3+ steps to 1 simple step. The downside is that the developer doesn't get as much say in how it appears in the database. The upside is that we now make the database persistence transparent.

2) Implement a few must-have changes to make it usable as a loader. Namely get updates working!

3) Implement root tag UIDs, and give the developer the option of determining the UID -- initially we'll have the timestamp, as Corby suggests, and a GUID -- probably a millisecond timestamp plus a decent bit of randomness run through an MD5 hash.

That's where we'll take Hibernex as a connector.

The next step is to use Hibernex as the springboard for generation two of this project, which may be given a different name and become a superset of this project. (Important: This project would not end.) It will involve creating an XQuery interface to allow XML-based CRUD. End-goal: To have a fully-functional XML database interface that is fast as hell.

RDBMS would still go through Hibernate, allowing the developer to choose what to use on the back-end, but all the SQL operations would be automated to make it transparent.

These are some example use cases:
+ Digest huge web service datasets (for instance the Zap2It TV guide included as an example) and be able to run fast dynamic queries on the data using XML->RDBMS translation. All this should be possible with Hibernex and no additional programming, except writing the actual query.
+ Read data for your website in XML format. Don't like the exact format you get? Run it through an XSLT stylesheet to get it to the schema you want, then through another one to generate your XML. Throw away those expensive mapping tools. (Sorry, webMethods.)
+ Need to share data with a business partner who doesn't like your vendor choices? Who cares, as long as you loaded it with XML to begin with. The back-end DB is invisible. Do a dump, and Hibernex would give you the whole dataset in one big XML file. Zip it and ship it via web service or FTP. They can run Hibernex to plug the data into a completely different database and won't have to care about any container-specific quirks.
+ Don't need any of this fancy stuff, and all you want to do is get a simple Java simple type value out of a web service you are digesting? Write a simple XQuery and you are done.

I have a name in my head for the new project, but we need to get this one into good shape first. I'm tied down for the next week and a half, after which I should be able to jump back into taking Hibernex the last mile as a data loader. Then we can start looking at making it a fully functional XML Data Access Layer.

- Carter
aka PapaLegba