Yuriy,
> Let me summarize the approaches:
I agree with your reasoning, p.2 sounds the best one to me as well.
Will look into merge-sort strategy some time later.
Best regards,
Ivan Pavlukhin
пт, 13 мар. 2020 г. в 19:23, Yuriy Shuliga :
>
> Ivan,
>
> I have made changes in the fork that
Ivan,
I have made changes in the fork that reflects merge-sort strategy and now
query future iterator unblocks as soon all first pages are delivered from
nodes; then it waits for the next pages portions and so on.
https://github.com/shuliga/ignite/commit/c84f04c18f67e99ab7bc0a7893b75f1dc83a76bd
Igniters,
Not intentionally the discussion continued outside of dev list. I am
returning it back. You can find it below. Do not hesitate to join if you
have some thoughts on raised questions. May be you have ideas how to enrich
text query results with score/rank information.
вт, 10 мар. 2020 г.
Hi Ivan,
Actually I have engaged another developer to help bring TextQueries to
correctly working state.
For now we have solution that adds Ordering functionality to distributed
TextQueries .
This is developed and tested locally. I can share details here, then we can
discuss and decide whether to
Hi Yuriy,
Just would like to realize current state. Are you still working on
Ignite text queries? If not, are you going to continue with it?
пт, 13 дек. 2019 г. в 11:52, Ivan Pavlukhin :
>
> Yuriy,
>
> Sure, I will be glad to help.
>
> > - incorrect nodes/partition selection during querying?
>
Yuriy,
Sure, I will be glad to help.
> - incorrect nodes/partition selection during querying?
Apparently this is the problem. If you feel it really complicated to
understand and debug then I can dig deeper and share my vision how the
problem can be fixed.
ср, 11 дек. 2019 г. в 18:46, Yuriy
I will look to the MOVING partition issue.
But also need a guidance there.
Ivan, don't you mind to be that person?
The question is whether we have an issue with:
- wrong storing targets during indexing OR
- incorrect nodes/partition selection during querying?
BR,
Yuriy Shluiha
--
Sent
Hello!
Yes, I guess you are right :(
I can surely fix the range issue, It's just that it was so broken that I
could not figure the correct behavior for this case.
Regards,
--
Ilya Kasnacheev
пн, 2 дек. 2019 г. в 15:01, Ivan Pavlukhin :
> Ilya,
>
> I checked your test on a revision before
*on topologies
вт, 3 дек. 2019 г. в 17:15, Ivan Pavlukhin :
>
> Ilya, Yuriy,
>
> It seems that text queries can return incorrect results on tologies
> with MOVING partitions. I left a comment in JIRA [1].
>
> [1] https://issues.apache.org/jira/browse/IGNITE-12401
>
> пн, 2 дек. 2019 г. в 15:00,
Ilya, Yuriy,
It seems that text queries can return incorrect results on tologies
with MOVING partitions. I left a comment in JIRA [1].
[1] https://issues.apache.org/jira/browse/IGNITE-12401
пн, 2 дек. 2019 г. в 15:00, Ivan Pavlukhin :
>
> Ilya,
>
> I checked your test on a revision before
Ilya,
I checked your test on a revision before "limit" and it fails there as
well. Could you please double check?
пн, 2 дек. 2019 г. в 13:21, Ilya Kasnacheev :
>
> Hello!
>
> The problem is NOT specific to range queries. Range queries were broken
> previously and they are broken now, but now
Hello!
The problem is NOT specific to range queries. Range queries were broken
previously and they are broken now, but now even a simple "token in field
with limit" returns duplicates.
Before limits were introduced, any tested use cases were unaffected by
duplicates, but now they are.
Regards,
And is the problem specific to range queries or not?
пн, 2 дек. 2019 г. в 11:12, Ivan Pavlukhin :
>
> Yuriy,
>
> Thank you for investigating the problem [1]. Still cannot realize how
> the problem relates to introduced "limit"? Is it right that there were
> no duplicates before "limit" support?
Yuriy,
Thank you for investigating the problem [1]. Still cannot realize how
the problem relates to introduced "limit"? Is it right that there were
no duplicates before "limit" support? After that support is introduced
are only limited queries contain duplicates, or unlimited, or both?
[1]
Hello!
I have just found what I consider a major regression in Text Queries: it
seems to me that text queries with limits will return same key-value
entries multiple times.
Please check the issue https://issues.apache.org/jira/browse/IGNITE-12401
and corresponding build
Nice to hear, Ivan
It's good practice to make existing functionality extension to be proper
presented; as we expect if from Text Queries.
Lets make it work correctly at first.
I'm ok to prepare ticket for adding reduction for sorted responses to
GridCacheDistributedQueryFuture or nearby.
Also
Folks, Yuriy,
I suppose that we are going to proceed with
>>>
Reducing on Ignite
The obvious point of distributed response reduction is class
GridCacheDistributedQueryFuture.
Though, @Ivan Pavlukhin mentioned class with similar functionality:
ReduceIndexSorted
What I see here, that it is
I don't see anything wrong if Yuriy is willing to carry on and keep
enhancing our full-text search support that lacks basic capabilities.
The basics should be available. If anybody needs an advanced feature they
can introduce Solr or ElastiSearch into the final architecture of the app.
Folks,
Folks,
IEP is an Ignite-specific thing. In fact, I suppose that we are
already doing it in ASF way by having this dev-list discussion =)
As for me, implementing "limit" feature for text queries is not so big
to make an IEP. But we might need to create one for next features.
вт, 26 нояб. 2019 г.
Hello!
ASF way should probably start with an IEP :)
Regards,
--
Ilya Kasnacheev
вт, 26 нояб. 2019 г. в 14:12, Zhenya Stanilovsky :
>
> Ok, lets forgot Solr and go through ASF way, if Yuriy prove this
> functionality is helpful and PR it, why not ?
>
> isn`t it ?
>
> >Вторник, 26 ноября 2019,
Ok, lets forgot Solr and go through ASF way, if Yuriy prove this functionality
is helpful and PR it, why not ?
isn`t it ?
>Вторник, 26 ноября 2019, 14:06 +03:00 от Ilya Kasnacheev
>:
>
>Hello!
>
>The problem here is that Solr is a multi-year effort by a lot of people. We
>can't match
21 matches
Mail list logo
