ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitriy Setrakyan <dsetrak...@apache.org>
Subject Re: golang client for Ignite
Date Thu, 29 Jun 2017 00:33:56 GMT
Denis,

Perhaps adding the same level of support for Golang as we have for .NET or
C++ would be asking too much. The reason we start a JVM in .NET and C++ is
because we implemented the full Ignite API support, even including
transactions and executing .NET closures on remote Java servers.

Perhaps, from Golang client standpoint, it is enough to implement it
directly over the REST protocol initially.

D.

On Wed, Jun 28, 2017 at 3:59 PM, Denis Magda <dmagda@apache.org> wrote:

> Aleksandr,
>
> > I take a look into ignite cpp core.
> > Looks like it attaches to running jvm and calls java methods.
> > Please tell me that I’m wrong! )))
>
> That’s a correct observation. Both C++ and .NET clients spawn a JVM
> process underneath and redirect almost all the requests to it. That
> approach allowed us to support these languages easily. Otherwise, it would
> have taken ages to develop true C++ and .NET libs.
>
> > It will not work for golang.
>
> Why?
>
> > Is there language-neutral protocol to communicate with Ignite server?
>
> REST, ODBC and JDBC only.
>
> —
> Denis
>
>
> > On Jun 28, 2017, at 12:43 PM, Aleksandr Sokolovskii <amsokol@gmail.com>
> wrote:
> >
> > Denis,
> >
> > I take a look into ignite cpp core.
> > Looks like it attaches to running jvm and calls java methods.
> > Please tell me that I’m wrong! )))
> >
> > It will not work for golang.
> > Is there language-neutral protocol to communicate with Ignite server?
> >
> > Thanks,
> > Aleksandr
> >
> > From: Aleksandr Sokolovskii
> > Sent: 28 июня 2017 г. 22:26
> > To: dev@ignite.apache.org
> > Subject: RE: golang client for Ignite
> >
> > Hi Deins,
> >
> > Thanks for answer.
> >
> > Link helps.
> >
> > It’s not good practice to call “c” functions from golang.
> > That’s why I develop client by pure golang without Ignite “cpp” client
> API.
> >
> > I already tested golang “handshake” using ODBC endpoint server:10800.
> > It works great.
> > But I don’t see support of transactions via ODBC...
> >
> > Yes, I would like to  develop true native client.
> > How can I get protocol specification to develop client BinaryMarshaller
> with pure golang?
> >
> > Thanks,
> > Aleksandr
> >
> > From: Denis Magda
> > Sent: 28 июня 2017 г. 2:00
> > To: dev@ignite.apache.org
> > Subject: Re: golang client for Ignite
> >
> > Hi Aleksandr,
> >
> > That looks really interesting to me. Personally, I would like to see a
> dedicated Go module in Ignite.
> >
> > Do you support SQL API right now? If it’s so then you might want to
> switch to Ignite JDBC driver instead that should outperform the REST
> protocol.
> >
> > Otherwise, if the goal is to go beyond SQL boundaries adding key-value
> and transactions to the list then we should either use the REST  or create
> a true native client. Read more about native clients development here:
> > http://apache-ignite-developers.2346864.n4.nabble.
> com/Read-this-if-you-want-to-integrate-Ignite-with-other-
> platforms-Python-R-etc-td14006.html#a14028
> >
> > —
> > Denis
> >
> >> On Jun 27, 2017, at 2:29 PM, Aleksandr Sokolovskii <amsokol@gmail.com>
> wrote:
> >>
> >> Dear Ignite team,
> >>
> >> I see there is no native client for golang.
> >> I tried to fix this gap a little bit and developed golang SQL driver
> for ignite/gridgain: https://github.com/amsokol/go-ignite-client.
> >> Enjoy ))).
> >> It's in beta phase now. I’m focusing on test coverage now.
> >>
> >> Driver uses HTTP REST API which is overhead.
> >> Could you please provide me specification of ignite native
> platform-independent client-server protocol.
> >> I easy add it as well.
> >>
> >> I think many people tell us thanks for golang native client and SQL
> driver )))
> >>
> >> P.S.: If you are interesting in my project please let me know. I can
> easy donate (and support) my code to your project.
> >>
> >> Thanks,
> >> Aleksandr
> >>
> >>
> >
> >
> >
>
>

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