*TOP SECRET FOR YOUR EYES ONLY*

(not really).

We want to avoid this:

Infinispan DB == Infinispan core + Persistence (disk/JDBC) + query (+ server, optionally)

With persistence and query modules, we have the makings of a "NoSQL" database (non relational datastore). Happily, the query module is shaping up to be quite powerful and avoid the conundrum described in the above cartoon.

Related: Distributed Query.

An object database (pojos)

As an object database, we are almost all set. Users push in pojos, with appropriate annotations for indexing. It is the responsibility of the users to generate unique keys (optional helper to create unique keys on request). Optional: have a mechanism for allowing indexing *other* then defined by the pojo itself.

Optional: JPA interface (not unlike the subset supported by Google App Engine) - JPA would store object itself in the grid, and JDBC driver (in which case fields are stored, not user objects).

As a non-sql database server

As a noSQL database, we can look to CouchDB for ideas on how this can operate - building on the REST server can help. Using JSON or XML as a records content can provide key/value indexing, which results in much simpler querying then CouchDB (but otherwise very similar, from any sort of client).

Pre reqs:

1) A object model for JSON/XML that is suitable for Infinispan Query (HS)

2) A query module with a SQL-like querying of Infinispan (useful for REST style interfaces)

3) A RESTful server to provide HTTP access handling the appropriate content-types, as well as ID creation and optimistic locking etc.

4) JDBC driver (maybe) to this server