Guys,
Thanks for your answers.
So If users want to use Ignite DataGrid from “unsupported” language they have
two choice for now:
1) REST API
It supports: cache management, put-get, sql exec queries, fetch
It does not support: sql transactions
REST API is easy to use.
REST API has a lot of overhead (HTTP, json marshalling/unmarshalling,.. you
know)
2) develop pure SQL driver for Ignite ODBC endpoint
It supports: sql exec queries, fetch
It does not support: cache management, put-get, sql transactions
Roman is right – using cgo is not very good idea.
Honestly It’s not trivial task to develop pure SQL driver for Ignite ODBC
endpoint.
I spent some hours to remember how STL serializes std::string to unmarshall it
in golang. )))
My last C++ experience was in 2004. )))
Another my concern is C++ wrapper over Ignite Java process.
I try to explain:
The main reason to develop something using golang is performance.
People how use golang are enslaved by performance.
They think how to avoid unnecessary memory allocation, avoid reflection, etc.
Go provides goroutine instead of system threads to avoid memory allocation and
cross-threads switching.
Cross-process switching (cpp->jvm->cpp) on server side of in-memory database
looks like “shot yourself in foot” for such people. )))
There is another way: to implement native client for H2 DB protocol.
(If I’m not mistaken Ignite use H2 DB protocol for JDBC endpoint).
Again it’s not trivial task to implement pure native H2 DB client for each
necessary programming language.
What do you think about to implement gRPC (or Apache Thrift, or…)
platform-language-neutral protocol endpoint in Java core of Ignite?
I resolves “unsupported” language client problem.
Thanks,
Aleksandr
From: Roman Shtykh
Sent: 29 июня 2017 г. 6:36
To: dev@ignite.apache.org
Subject: Re: golang client for Ignite
Guys,
Just an observation, but when I introduce Ignite to other developers, they get
very interested. But when the question goes to the support of the language they
use for development, often they look disappointed because a chunk of
functionalities I introduce becomes inaccessible. I think from their NoSQL
experience they expect a client protocol.
As for Golang, from what I know, you have to write bindings in C for C++ and
use them. There are performance concerns with cgo.
-- Roman
On Thursday, June 29, 2017 9:34 AM, Dmitriy Setrakyan
<dsetrak...@apache.org> wrote:
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 <dma...@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 <amso...@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 <amso...@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
> >>
> >>
> >
> >
> >
>
>
