I think we can invite them to our virtual meetup and share details. Your
thoughts?
чт, 28 окт. 2021 г. в 10:15, Ivan Pavlukhin :
> Hi Maximiliano,
>
> Thank you for pointing this out, rather interesting. Have you tried to
> communicate with a hawkore team? I doubt that anyone in Community
> knows
Hi Maximiliano,
Thank you for pointing this out, rather interesting. Have you tried to
communicate with a hawkore team? I doubt that anyone in Community
knows implementation details of hawkore additions.
2021-10-22 19:58 GMT+03:00, Maximiliano Gazquez :
> Hello everyone!
>
> I wanted to add this
Hello everyone!
I wanted to add this to the discussion.
I've found this project https://github.com/hawkore/ignite-hk which promises
to solve most of the issues that are being discussed here like pagination,
sorting and most important, persisting the lucene index.
It does stuff like this to create
Hi Atri,
Sorry for a late answer.
> I didn't quite understand. Are you proposing that Ignite should not have FTS
> capabilities?
It seems an option to me. IMHO it is better to have no FTS instead of
something like current Ignite TextQueries.
2021-08-03 12:45 GMT+03:00, Atri Sharma :
> Hi Ivan,
Hi Ivan,
I didn't quite understand. Are you proposing that Ignite should not
have FTS capabilities?
Atri
On Tue, Aug 3, 2021 at 2:57 PM Ivan Pavlukhin wrote:
>
> Hi Atri,
>
> My main concern is non-maleficence. Every task has several solutions,
> e.g. straightforward ones:
> 1. Do not implement
Hi Atri,
My main concern is non-maleficence. Every task has several solutions,
e.g. straightforward ones:
1. Do not implement FTS.
2. Create own implementation.
Some of the strongest ones live without FTS [1].
[1] https://github.com/cockroachdb/cockroach/issues/7821
2021-08-02 11:33 GMT+03:00,
Hi Ivan,
Would you like to propose an alternative to Lucene?
Atri
On Mon, 2 Aug 2021, 13:48 Ivan Pavlukhin, wrote:
> Folks,
>
> Sorry if read the thread not thoroughly enough, but do we consider
> Lucene as obviously right choice? In my understanding Ignite history
> has shown clearly that "fa
Folks,
Sorry if read the thread not thoroughly enough, but do we consider
Lucene as obviously right choice? In my understanding Ignite history
has shown clearly that "fastest feature implementation" is not usually
the best. And one example of this are text queries. Are not we trying
to do a same m
Andrey,
> Per-partition Lucene index looks simple to implement, but it may require
> per-partition SQL to make full-text search expressions work correctly
> within the SQL quiery.
I think that as long as we follow the map - reduce process that we
already do for other queries, we should be fine.
>
Atri,
> We can have partition level indices on each node.
Per-partition Lucene index looks simple to implement, but it may require
per-partition SQL to make full-text search expressions work correctly
within the SQL quiery.
Per-partition SQL index may kill the performance. We already tried to do
t
Sorry, I planned on creating a Wiki page for this, but it makes more
sense to be replying here.
> * How Lucene index can be split among the nodes?
We can have partition level indices on each node.
> * If we'll have a single index for all partitions on the particular node,
> then how index record
Hello!
Let me try to answer the questions below, since I did not see anybody do
that and thus not everybody may be on the same page.
Regards,
пт, 23 июл. 2021 г. в 13:56, Andrey Mashenkov :
> Atri,
>
> As for now, the potential capabilities are not clear to me.
> At first glance, I see the next
+1 we're all saying the same thing here.
My example from before select x from T0 where term(args to solr term query)
AND ..
term(xxx) was meant to indicate a lucene term query and so there'd be a
list of lucene functions exposed in a similar way.
On Mon, Jul 26, 2021 at 5:45 PM Atri Sharma wrot
+1
Lets expose custom functions in Ignite SQL which allows us to use the full
capabilities that Lucene offers
On Mon, 26 Jul 2021, 21:51 Andrey Mashenkov,
wrote:
> Val,
>
> > I believe this is something we can look into in the scope of Ignite 3.
> > Andrey, does Calcite have any support for thi
Val,
> I believe this is something we can look into in the scope of Ignite 3.
> Andrey, does Calcite have any support for this? What's your view on this?
As Atri already mentioned, SQL 92 standard declares "LIKE" operator for
pattern matching.
Calcite supports LIKE operator.
I've found it is a R
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 doesn'
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 d
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 imple
Atri,
Sure, go ahead. Let's put the ideas on paper and have a discussion.
-Val
On Fri, Jul 23, 2021 at 10:59 AM Atri Sharma wrote:
> Thanks Andrey.
>
> I have collected answers or proposals to many of these questions and
> would like to start a wiki page covering what we can do for Ignite 3.
>
It surely will not be supported out of the box, but in my understanding
Calcite provides enough flexibility for us to develop these features in a
way we would like to see them.
Andrey, please correct me if I am wrong here.
-Val
On Fri, Jul 23, 2021 at 10:58 AM Atri Sharma wrote:
> The standard
Thanks Andrey.
I have collected answers or proposals to many of these questions and
would like to start a wiki page covering what we can do for Ignite 3.
Does that sound good, please?
On Fri, Jul 23, 2021 at 4:26 PM Andrey Mashenkov
wrote:
>
> Atri,
>
> First of all, I'd recommend going through
The standard ways to deal with text based searches in SQL are the
CONTAINS operator, the LIKE operator or specific functions
(REGEXP_MATCHES, for eg). I do not think any of these are supported by
Calcite at the moment.
On Fri, Jul 23, 2021 at 11:20 PM Valentin Kulichenko
wrote:
>
> In my experien
In my experience, one of the biggest usability issues with the current
support of text queries is that they are completely decoupled from SQL.
I.e. you can either execute a SQL query OR a text query. Modern databases,
on the other hand, typically allow creating text-based indexes within
regular tab
Atri,
First of all, I'd recommend going through the Ignite ticket to gather
information about the current implementation issues and users' wants.
Then look at a code to get a complete understanding of how things work now,
which may help in future decisions.
As we use the outdated Lucene version,
I am actually happy to drive the feature for Ignite 3. FTS is very
important for me and I think Ignite users will benefit from it
greatly.
If it makes sense to be focusing on Ignite 3 for this capability, I am
eager to contribute there and lead the development.
Please share your thoughts.
On Fri
Hi Atri,
All the Jira tickets we have on the Full-text search (FTS) thing are
targeted to Ignite 2.
AFAIK, we want, but we have NOT committed to FTS support in Ignite 3, yet.
By the way, we are getting requests for this thing from the user side, and
definitely,
FTS would be a valuable feature for
Hello,
An update, please. I am working through persistence of Lucene index using
Ignite Dictionary, and will be asking some questions soon.
I had one doubt - - where does this change go? Ignite 3?
Also, I know we want to build native support for text searches in Ignite 3.
Is the work I am propos
Hello!
I think that number one is the most important one, then maybe it will see
more use and other deficiencies become more apparent, leading to more
tickets and visibility.
Maybe 2. and 3. will even use a different approach when persistence is
implemented.
Regards,
--
Ilya Kasnacheev
пн, 28
Hello Again!
I have been looking into the aforementioned and here are my follow up thoughts:
1. Support persistence of Lucene indexes.
2. https://issues.apache.org/jira/browse/IGNITE-12401 (Needs fixing of
moving partitions first)
3. Figure out how to return scores from nodes and use them as sort
Thank you, Maksin and Alexei!
To dive a bit deeper, what are our biggest issues with text queries
today? One is persistence, the other (IIUC) is the fact that we cannot
order results from different nodes (which PR 9081 seems to have
resolved?)
What else would be pending for text queries to become
Hi.
One of the biggest issues with text queries is a lack of support for lucene
indices persistence, which makes this functionality useless if a
persistence is enabled.
I would first take care of it.
пн, 21 июн. 2021 г. в 12:16, Maksim Timonin :
> Hi, Atri!
>
> You're right, Actually there is a
Hi, Atri!
You're right, Actually there is a lack of support for TextQueries. For the
last ticket I'm doing I see some obvious issues with them (no page size
support, for example). I'm glad that somebody wants to maintain this
functionality. Thanks a lot!
For the MergeSort algorithm there is alrea
32 matches
Mail list logo
