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, <[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
