Hi Denis,
I don`t see any problem here, i have to speak with @vozerov about this
issue and he recommends me to write it into dev list. All problems that i
have with swig is :
1. jni overhead (no miracle here ...)
2. light troubles with collections API wrapping, like std::map, std::list
and so on.
Partially my open source FreeLing java wrapper you can see here
https://github.com/TALP-UPC/FreeLing/tree/master/APIs/java
std_list.i - little stub :) i have talking about.
Hi Evgeniy,
Presently we’re trying to fill this gap offering SQL Grid [1]. In a
nutshell, you can connect to an Ignite cluster from your favorite
language or tool with ODBC/JDBC drivers and work with the cluster using
SQL SELECT, INSERT, UPDATE, DELETE statements.
Here is how everything works for PHP that is not natively supported by
Ignite:
https://dzone.com/articles/apache-ignite-enables-full-fledged-sql-support-for
However, as for SWIG. Do you think it’s feasible to implement on top of
Ignite.C++ client which is tightly coupled with JVM?
[1] https://apacheignite.readme.io/docs/sql-grid
<https://apacheignite.readme.io/docs/sql-grid>
—
Denis
On Jan 16, 2017, at 11:46 PM, Evgeniy Stanilovskiy
<estanilovs...@gridgain.com> wrote:
Hi all.
Not so long ago i had to know that ignite had reduced functionality
support in scripting languages.
So, idea was to take an existing C++ client and using SWIG
(http://www.swig.org) as automatic wrapper, generate clients for
absence scripting languages.
What do you think about this case ?
Thanks !
