asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Carey <>
Subject Re: JDBC Driver for AsterixDB and how other NoSQL dbs did it
Date Wed, 08 Mar 2017 18:13:14 GMT
Cameron, Siddesh, et al:

One more thought:  One thing that could be Very Cool about a JDBC driver 
would be that it would enable the use of AsterixDB from BI reporting 
tools.  It would be restrictive - it could insist that the queries 
return flat/regular results (like when we export data results in CSV 
form) - but it would be really enabling from a reporting tool users 
standpoint. AsterixDB developers/analysts could then create views 
(CREATE FUNCTION myview ( ) AS ...) whose results are flat and which 
could be queried from the tool.

There are basically two potential target audiences for Java/AsterixDB - 
app developers who want to write Java apps with an AsterixDB backend - 
hence perhaps JPA - or analysts who want to hook AsterixDB up to their 
favorite reporting tools - hence JDBC. (For the latter, the SQL++ query 
language would have to be the target, and we'd have to see if the SQL 
issued from them passes SQL++ muster.)



On 3/8/17 7:08 AM, Cameron Samak wrote:
> 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, <> 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
>> jira/browse/ASTERIXDB-1369 (
>> 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 (
>> (
>> SQL_Support))
>>          * MongoDB provides JPA/JDO through DataNucleus and Hibernate OGM (
>> (
>>   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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message