Hi,
Artifacts were uploaded to the maven repo [1, 2, 3, 4].
The spring-tx module was migrated in the 2.11 that was not released yet.
The extension release is independent of the Ignite release.
[1]
https://mvnrepository.com/artifact/org.apache.ignite/ignite-spring-data-ext
[2]
Hey Ari,
Yes, I wasn't suggesting that Solr should be used. That's just what we're
doing now out of necessity.
It was more the fact that Calcite's SqlOperator can be used to provide the
interface to Lucene.
For all the reasons you mentioned and more, using Lucene is the right choice
Calcite
What that entails is that the end user has to keep a Solr cluster running,
which comes with its own challenges (now you have to manage two systems
instead of one).
I believe Calcite has native support for Solr?
OTOH, having native Lucene indices allow us to control per partition
indices with no
I'll add in here.
I agree with you Valentin, the decoupled state of text queries makes it
useless for most use cases we have.
As it relates to Calcite and Ignite 3, one approach (the one we're taking
because we use calcite independent of Ignite) is to provide a bunch of SQL
functions that we
Hi Igniters,
I've detected some new issue on TeamCity to be handled. You are more than
welcomed to help.
*New Critical Failure in master Basic 1
https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Basic1?branch=%3Cdefault%3E
No changes in the build
*New test failure
