Greetings,
Currently AsterixDB does not provide any standard database access solution for 
Java such as JDBC/JPA. This issue was discussed in the mailing list and the 
JIRA issue is available at https://issues.apache.org/jira/browse/ASTERIXDB-1369 
(https://issues.apache.org/jira/browse/ASTERIXDB-1369). A lot of enterprise 
Java software uses or is built on top of JDBC so its definitely important for 
AsterixDB to have some form of JDBC connectivity to be considered for such 
applications.
Since JDBC is meant for RDBMS, making a driver for a semi-structured database 
like AsterixDB wont be straight forward.

Lets see how other NoSQL databases have done it 
        * Cassandra, HBase and MongoDB provide a custom Java client library 
which provides either custom data types or ORM facilities. It is not JDBC 
compliant 
        * HBase provides JDBC connectivity via Apache Phoenix 
(http://phoenix.apache.org/#SQL_Support 
(http://phoenix.apache.org/#SQL_Support)) 
        * MongoDB provides JPA/JDO through DataNucleus and Hibernate OGM 
(https://docs.mongodb.com/ecosystem/drivers/java/ 
(https://docs.mongodb.com/ecosystem/drivers/java/)) 

 For AsterixDB here are some possible solutions in increasing order of 
difficulty  
        * Make a custom client library which is a thin wrapper that makes HTTP 
requests to the REST API, gets back data as JSON and then uses Jackson (or 
Gson) for mapping JSON to POJO. Use only standard Java Collections 
        * Provide a JDBC driver that again makes HTTP requests to REST API and 
receives results in CSV and maps that to columns in RowSet. We may choose to 
drop any extra fields that come up in open data types or put them in the last 
column as JSON string. Also when I tested the CSV output mode of AsterixDB 
webapp it wasnt working well 
        * Create a plugin for another JPA/JDO framework like DataNucleus or 
HibernateOGM (or Spring Data? i haven't gone in depth on that one). These 
frameworks are popular with devs and provide a lot of other functionality. 

 I need the community's feedback on what approach they think would be right.
I'm willing to work on this issue as part of GSOC so if any potential mentors 
are interested, please reply.

Regards
Siddhesh Rane

Reply via email to