JDBC Driver for Oracle NoSQL Database

JDBC hardly needs any introduction. JDBC spec was released 30 years ago, in 1977 with Java version 1.1. Since then, JDBC has been widely adopted. Mostly used with RDBMS databases. Every RDBMS provides a JDBC driver.

But a JDBC driver for Oracle NoSQL database?
Wait ! There are two questions:
    What is Oracle NoSQL database?
    JDBC is for SQL. Why JDBC driver for NoSQL database?

Oracle NoSQL Database  is the best well-kept secret of NoSQL world. It is one of the best NoSQL database technical capability and performance wise. It is also least known. Though some serious, large-scale, global application runs on Oracle NoSQL database, it is hardly known widely as google or stackoverflow would show.

Oracle NoSQL is a distributed database. It is scalable, elastic. At its core lies robust and time-tested kernel of BerkeleyDB. Oracle NoSQL database overlays a network fabric over a set of BerkleyDB kernels to deliver a high-performance, low-latency distributed database that even provides transactional warranty in limited sense. 

Oracle NoSQL database, though a key-value database at its core, already provides a tabular view. And supports a query language that is quite similar to SQL. So, it is a natural and logical to have a JDBC driver for  Oracle NoSQL database. This blog introduces such a JDBC driver.

As I mentioned earlier, JDBC has been around and does not need to be repeated. Oracle JDBC driver is compliant to JDBC Spec version 4.2.

I would mention only one aspect of new JDBC driver. Its' powerful capacity to store, retrieve and query user-defined objects.

One of the major attractiveness of NoSQL  database is flexible schema. Oracle database natively supports JSON data type to store tree like nested data structure. JDBC driver builds on top of that native JSON facility  to support object support with polymorphic type preservation.

For a developer, it means that database remembers (databases typically have excellent memory) the runtime type of an object being stored. And later retrieve the object with the same type.

Let us assume an interface: Human. The interface is implemented by two concrete classes Male and Female.

Now, when an object is stored, its runtime type is not Human which is an interface but an instance of concrete type: Male or Female. Later the object can be realized in memory as a Male or Female type, not only as a Human.

Moreover, polymorphic relationship is also supported. Let us say, two humans are related by partner relationship. The relationship is declared at  Human level. For example,
     Human getPartner()

But when an object is stored, the partner object is either a Male or Female. Again, the object graph is retrieved with type information preserved. So if a Male who has a Female partner is stored, when retrieved, the partner would be an instance of a Female object.

No comments:

Post a Comment

New trillion