Note: after HSEARCH-3399, it might _seem_ that this problem is solved, but it is not. In particular the codecs only have one "isCompatibleWith" method that checks data related to multiple features (projections, sorts), and is called from the predicate/sort/projection factories despite being too coarse-grained.
See the comment starting with "Unrelated to your PR, but this is the kind of thing that makes {{isCompatible}} methods too coarse-grained" on [this PR| https://github.com/hibernate/hibernate-search /pull/1778/]
Also note: we really need explicit tests for compatibility checks, preferably checking all possible combinations of types (string+string, string+date, date+date, date+integer, etc.), and checking all three DSLs (predicate, sort, projection). If possible, unit tests would probably be better, given the they are faster and we need to test many combinations.
- --
Original description:
See https://github.com/hibernate/hibernate-search- 6-poc/pull/93/files/1a8c67d4002e5642fcfd782dfad0468a6b45a088..6249c1bbd63ed870e8fa0b33e50e3572de235f9b#r214029552
In particular this:
{quote}
Then, the {{isCompatibleWith}} method is really too coarse-grained. At some point we will need multiple ways to determine "compatibility" between indexes, because being compatible when projecting is not the same as being compatible when defining predicates, for example. Right now we just enforce the strictest (and most limiting) definition of "being compatible".
{quote} |
|
