You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@asterixdb.apache.org by si...@disroot.org on 2017/03/08 08:25:17 UTC

JDBC Driver for AsterixDB and how other NoSQL dbs did it

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

Re: JDBC Driver for AsterixDB and how other NoSQL dbs did it

Posted by Mike Carey <dt...@gmail.com>.
Another approach that several vendors are following (e.g., DB2) is to 
postulate MongoDB as a winner of the client-side API wars for JSON and 
provide a look-alike API. (Cameron has experience there too.)


On 3/8/17 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
>


Re: JDBC Driver for AsterixDB and how other NoSQL dbs did it

Posted by Mike Carey <dt...@gmail.com>.
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, <si...@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
>>


Re: JDBC Driver for AsterixDB and how other NoSQL dbs did it

Posted by Cameron Samak <cs...@apache.org>.
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, <si...@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
>