Mailing-List: contact dev-help@asterixdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@asterixdb.apache.org
Subject: Re: JDBC Driver for AsterixDB and how other NoSQL dbs did it
To: dev@asterixdb.apache.org
References: <a0bc6285cd74e1ffc03b5710b4f26c16@cloud.disroot.org>
 <CA+oowjG_+=sUHc4kVzFg_xzYqLd6JAHByfdD-JSugt3N5a1MHw@mail.gmail.com>
From: Mike Carey <dtabass@gmail.com>
Message-ID: <13468fb8-5056-3dee-5459-fd3d4ff2b1c6@gmail.com>
Date: Wed, 8 Mar 2017 10:13:14 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0)
 Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <CA+oowjG_+=sUHc4kVzFg_xzYqLd6JAHByfdD-JSugt3N5a1MHw@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------5EE53FA68056B6E69D7C5D26"
archived-at: Wed, 08 Mar 2017 18:13:23 -0000

--------------5EE53FA68056B6E69D7C5D26
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

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.)

Cheers,

Mike


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, <siddheshrane@disroot.org> 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
>>


--------------5EE53FA68056B6E69D7C5D26--