Hi Siddhesh, Maybe others have a different opinion on this, but I'm not convinced that implementing an actual JDBC driver would be a good first Java client as it would be quite restrictive. Once a more generic client exists, then creating a JDBC driver might be useful to integrate with tooling that expects one.
The other two options you suggested don't seem mutually exclusive to me. Something that allows JPA/JDO access could reuse much of a thin HTTP API wrapper in its implementation. Since a thin wrapper would be very useful by itself, I think it's best to start with that and then reuse parts of it to build something like JPA/JDO support. Thanks, Cameron On Wed, Mar 8, 2017 at 12:25 AM, <[email protected]> wrote: > 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 >
