Andrey, there is no IEP for Java API for SQL and would be great to have it. I'll create the IEP soon.
On Fri, May 20, 2022 at 1:56 PM Andrey Mashenkov <andrey.mashen...@gmail.com> wrote: > > JFYI. we have merged the initial version of SQL public API [1] and are > going to implement it in epic [2] and I've created few tickets on this. > > Andey Gura, Taras Ledkov, Konstantine Orlov would you mind to share your > thoughts on implementation part in some IEP? > Is there IEP page created on the topic? > > [1] https://issues.apache.org/jira/browse/IGNITE-15212 > [2] https://issues.apache.org/jira/browse/IGNITE-16952 > > On Tue, Apr 6, 2021 at 4:23 PM Andrey Mashenkov <andrey.mashen...@gmail.com> > wrote: > > > Hi Taras. > > > > 1. AFAIK, only Thin clients will be available in 3.0. > > However, yes, Native JDBC API is still "must have" on servers. > > > > 2. We won't have other projects in dependencies if possible. Unless > > we/they are Jigsaw compatible though. > > > > 2.1 I think it makes sense to be an R2DBC-compatible as it is a widely > > used framework. E.g. Spring supports R2DBC [1]. > > Having an extension with R2DBC support will make Spring integration with > > Ignite easy in the future. > > > > If it will be enough to have a dependency on just reactive-streams API [2], > > then adding this API to dependencies looks ok to me, as there are only a > > few interfaces and converters to/from JDK Flow API. > > And the question is would we go with Flow API or Reactive-Streams? > > > > If we need some more than reactive-streams API, then I would suggest to go > > with Flow API. > > > > 2.2 ADBA is compatible with R2DBC but was discontinued [3]. > > > > 2.3 I don't think custom API is ever useful. We will need > > converters/adapters to Flow or Reactive-streams for easy integration with > > other APIs/frameworks. > > Otherwise, uses will have difficulties interacting with Ignite in a > > reactive way. > > > > [1] > > https://spring.io/blog/2018/12/07/reactive-programming-and-relational-databases > > [2] https://github.com/reactive-streams/reactive-streams-jvm > > [3] > > https://mail.openjdk.java.net/pipermail/jdbc-spec-discuss/2019-September/000529.html > > > > On Tue, Apr 6, 2021 at 3:05 PM Taras Ledkov <tled...@gridgain.com> wrote: > > > >> Hi, > >> > >> Ignite 3.0 requires a rethinking of the query API. > >> We have 'cache.query()' and 'SqlFieldQuery' abstractions at the Ignite > >> 2.x native API and several JDBC implementation for clients. > >> > >> I propose to think about new query/SQL API for the Ignite 3.0. > >> > >> My vision is something like this: > >> Ignite will support two query APIs: standard JDBC (on native) and one of > >> reactive DB API. > >> > >> 1. Native JDBC API, e.g.: > >> Connection conn = node.sql().connection(props); > >> > >> JDBC is the industrial standard of the DB access and we have to support > >> one. > >> Also: > >> 1.1. Thin JDBC client will be really thin: provide network communication > >> layer and transparently map to native API. > >> 1.2. Thick JDBC client implementation will be trivial: start client node > >> and open JDBC connection on the started node. > >> 1.3. JDBC provides sufficient functionality to implement ODBC (need to > >> investigate: may be thin protocol may be extended to unify JDBC and ODBC). > >> > >> 2. About reactive DB API. > >> I don't know of any industrial standard API for DB reactive access now. > >> There are several candidates: > >> 2.1. R2DBC look like the popular and alive. See [1]; > >> 2.2. ADBA (java.sql2 [2]) looks like not alive. Not sure; > >> 2.3. Custom async/reactive API. > >> e.g. oracle DB use this way [3]. > >> > >> Igniters, WDYT? > >> > >> [1]. https://github.com/r2dbc/r2dbc-spi > >> [2]. > >> http://cr.openjdk.java.net/~lancea/apidoc/java/sql2/package-summary.html > >> [3]. > >> > >> https://docs.oracle.com/en/database/oracle/oracle-database/21/jjdbc/jdbc-reactive-extensions.html#GUID-1C40C43B-3823-4848-8B5A-D2F97A82F79B > >> > >> -- > >> Taras Ledkov > >> Mail-To: tled...@gridgain.com > >> > >> > > > > -- > > Best regards, > > Andrey V. Mashenkov > > > > > -- > Best regards, > Andrey V. Mashenkov
