I was recently thinking on my way to Downtown Toronto to see my friend and cherry blossoms about all these NOSQL, not only SQL, databases and was thinking how most of them do not have a vendor neutral interface akin to that of JDBC or JPA etc.Â So I was thinking maybe they should have one, but personally I’d rather it reuse as much of the existing API as possible.
So my first question to myself is which one would I choose as the base? JDBC or JPA?Â After mulling it for a couple of minutes, I said let’s start with JDBC because we should have a lower level API and those would be easier for vendors to implement.
So I was then contemplating on what features we should have and what is common among some of the more popular NOSQL database patterns (e.g. social graphs via Neo4J, key value data stores such as BDB, document databases such as Lotus Notes)
One thing that stood out among all of them is the notion of a unique ID that represents the object.Â So the API should have something like:
Well now that we have an egg (i.e. method) we need a chicken (i.e. class/interface name).Â I was thinking of javax.objectdatabase.ObjectDataSource
Another thing they would have are queries that are not SQL, but ideally they need to follow the same pattern as JDBC PreparedStatement.Â So I would expect a method like
ObjectDataSource.prepareStatement(String query, Class clazz);
ObjectDataSource.prepareStatement(String query, Map<> queryHints, Class clazz);
That way provides can cache or precompile the query in their backend and execute it with parameters provided.
I would have some providers optionally provide PreparedStatmentMetaData.getParameterNames that list the names of the parameters.Â Also PreparedStatementMetaData.getParameterType(String name) to get the type of the parameter.
The last requirement I would have of the API is that it supports XA transactions so we can rollback the changes if needed.
With this, at least we Java developers do not need to know a new API for every object data store.