Exception Predicate targets unexpected fields when use nested() in sort filter

Description

When use:

An exception was thrown:

Environment

None

Activity

Show:
Waldemar Kłaczyński
April 11, 2020, 9:30 PM
Edited

Maybe you should not create a "nestedPathHierarchy" sub list in the "LuceneNestedPredicateBuilder" class. Then subtract the element if this is the type "LuceneNestedPredicateBuilder" in "AbstractLuceneNestablePredicateBuilder#build"?

This solution corrected this error.

Yoann Rodière
April 14, 2020, 7:05 AM

This exception is on purpose. The predicate passed as sort filter should only be referring to fields in the same nested document as the sort field, or a more deeply nested document; otherwise the filter just cannot work. See .

This code would work just fine:

Note that's a bit complicated, but only because of the native query. Without it, we wouldn't have to use an explicit nested predicate to begin with.

As to your patch, I'm a bit concerned it will allow "nesting" multiple nested predicates on the same object field, which I do not think will work correctly. Something like this:

I will close this ticket for now, as I provided a solution to your problem. If that's not an acceptable solution, please feel free to re-open this ticket.

Waldemar Kłaczyński
April 14, 2020, 6:57 PM

I know you can do that. But then you need to submit the filter for sorting and searching separately. The idea is to use the same filtering query and not worry about how to use it when sorting and searching differently. This is important for very complex filters, where it is necessary to use the nesting predicate once and in other cases it should not be used. PR should be able to adapt himself. Do not throw exceptions, require some complex actions.

 

In this case it would not be possible. My patch makes it possible. Just when building a query, it decides by context how to build a filter.

Waldemar Kłaczyński
April 14, 2020, 7:03 PM

I know you can do that. But then you need to submit the filter for sorting and searching separately. The idea is to use the same filtering query and not worry about how to use it when sorting and searching differently. This is important for very complex filters, where it is necessary to use the nesting predicate once and in other cases it should not be used. PR should be able to adapt himself. Do not throw exceptions, require some complex actions.

In this case it would not be possible. My patch makes it possible. Just when building a query, it decides by context how to build a filter.

Waldemar Kłaczyński
April 14, 2020, 7:43 PM

The user could define filters as you presented. Maybe it is better to allow more if it is forbidden. Now the code is getting too complicated. Dividing queries later, submitting them according to the use case is inefficient and complicates the code. You can't prepare filtering patterns, querying dynamic models. Building separate filters for sorting and searching, and in the future and aggregation will be too complicated.

After that, even if the user duplicated the predicates, they will be optimized. This is in my patch. But it will be possible to bus complex predicates in satatic methods as well as in native filters. Sometimes over-straining the nesting predicate as an indication that an element should be nested if the context requires it.

Assignee

Yoann Rodière

Reporter

Waldemar Kłaczyński

Labels

None

Suitable for new contributors

None

Pull Request

None

Feedback Requested

None

Components

Affects versions

Priority

Major
Configure