3:58 a.m.
DSL API doesn't build the correct Lucene query
----------------------------------------------
Key: HSEARCH-917
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-917
Project: Hibernate Search
Issue Type: Bug
Components: query
Affects Versions: 3.4.1.Final
Reporter: Guillaume Smet
Priority: Critical
Hi,
A bit of context:
We are early adopters of Hibernate Search and we have very few problems with it (except
the @IndexEmbedded problem we helped to fix in 3.4.1, no problem so far).
When the DSL API was introduced, I tried it and I found the problem I describe below. I
decided to use the QueryParser API (and the MultiFieldQueryParser API) as a workaround.
The fact is that:
* we use Hibernate Search in every application we have, now;
* the DSL API is really nice and, as we introduced QueryDSL in our application, we now use
a lot of DSL like API and I would like to be able to use Hibernate Search API too;
* I thought it was a deliberate choice but, recently I found an example so weird, I
can't think it's the wanted behaviour.
So this problem isn't new and it exists since the first version of the DSL API.
Now, the description of the problem:
* we use the following analyzer to index a field in our entity:
{code}
@AnalyzerDef(name = HibernateSearchAnalyzer.TEXT,
tokenizer = @TokenizerDef(factory = WhitespaceTokenizerFactory.class),
filters = {
@TokenFilterDef(factory = ASCIIFoldingFilterFactory.class),
@TokenFilterDef(factory = WordDelimiterFilterFactory.class, params = {
@org.hibernate.search.annotations.Parameter(name = "generateWordParts",
value = "1"),
@org.hibernate.search.annotations.Parameter(name =
"generateNumberParts", value = "1"),
@org.hibernate.search.annotations.Parameter(name = "catenateWords",
value = "0"),
@org.hibernate.search.annotations.Parameter(name = "catenateNumbers",
value = "0"),
@org.hibernate.search.annotations.Parameter(name = "catenateAll", value
= "0"),
@org.hibernate.search.annotations.Parameter(name = "splitOnCaseChange",
value = "0"),
@org.hibernate.search.annotations.Parameter(name = "splitOnNumerics",
value = "0"),
@org.hibernate.search.annotations.Parameter(name = "preserveOriginal",
value = "1")
}
),
@TokenFilterDef(factory = LowerCaseFilterFactory.class)
}
),
{code}
* the content of the field is something like XXXX-AAAA-HAGYU-19910
* if you search for an exact match "XXXX-AAAA-HAGYU-19910" with the QueryParser,
you have a few results: namely the results which have all the different parts (XXXX, AAAA,
HAGYU and 19910) in any order. That's the behaviour I expect considering my analyzer.
* if you search using the DSL API, you have ALL the results containing at least ONE token
so A LOT of results in our case.
My expectation is that the DSL API should work as the Lucene parser works and it should
return the same results.
The problem is that in ConnectedMultiFieldsTermQueryBuilder, we don't use the
QueryParser to build the Lucene query but a getAllTermsFromText() method which uses the
analyzer to get all the terms and from that we build a OR query.
So when I search for XXXX-AAAA-HAGYU-19910, the DSL API searches for "XXXX" OR
"AAAA" OR "HAGYU" OR "19910".
I really think it's a mistake and that we should use the *QueryParser API to build the
Lucene Query and have the correct behaviour.
If needed, I can provide any further information and/or a test case. I just want to be
sure you consider it a bug before working further on this. Otherwise I'll stick to
using the *QueryParser API.
Thanks for your feedback.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
7:22 a.m.
New subject: [Hibernate-JIRA] Commented: (HSEARCH-917) DSL API doesn't build the correct Lucene query
[
http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-917?pag...
]
Emmanuel Bernard commented on HSEARCH-917:
------------------------------------------
There are two main reasons I have decided to go for the OR option:
- if you use OR, you also retrieve results matching AND and usually the AND results are on
top
- to support tokenizers like NGRAMs, you must use OR and that's the main reason behind
my choice.
But I'm happy to add a new setting if needed.
{code}
Query query = builder
.keyword()
.onField( "uuid" )
.matching( "XXXX-AAAA-HAGYU-19910" )
.mustMatchAllTerms() //or a better name
.createQuery();
{code}
WDYT?
DSL API doesn't build the correct Lucene query
----------------------------------------------
Key: HSEARCH-917
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-917
Project: Hibernate Search
Issue Type: Bug
Components: query
Affects Versions: 3.4.1.Final
Reporter: Guillaume Smet
Priority: Critical
Hi,
A bit of context:
We are early adopters of Hibernate Search and we have very few problems with it (except
the @IndexEmbedded problem we helped to fix in 3.4.1, no problem so far).
When the DSL API was introduced, I tried it and I found the problem I describe below. I
decided to use the QueryParser API (and the MultiFieldQueryParser API) as a workaround.
The fact is that:
* we use Hibernate Search in every application we have, now;
* the DSL API is really nice and, as we introduced QueryDSL in our application, we now
use a lot of DSL like API and I would like to be able to use Hibernate Search API too;
* I thought it was a deliberate choice but, recently I found an example so weird, I
can't think it's the wanted behaviour.
So this problem isn't new and it exists since the first version of the DSL API.
Now, the description of the problem:
* we use the following analyzer to index a field in our entity:
{code}
@AnalyzerDef(name = HibernateSearchAnalyzer.TEXT,
tokenizer = @TokenizerDef(factory = WhitespaceTokenizerFactory.class),
filters = {
@TokenFilterDef(factory = ASCIIFoldingFilterFactory.class),
@TokenFilterDef(factory = WordDelimiterFilterFactory.class, params = {
@org.hibernate.search.annotations.Parameter(name =
"generateWordParts", value = "1"),
@org.hibernate.search.annotations.Parameter(name =
"generateNumberParts", value = "1"),
@org.hibernate.search.annotations.Parameter(name = "catenateWords",
value = "0"),
@org.hibernate.search.annotations.Parameter(name = "catenateNumbers",
value = "0"),
@org.hibernate.search.annotations.Parameter(name = "catenateAll",
value = "0"),
@org.hibernate.search.annotations.Parameter(name =
"splitOnCaseChange", value = "0"),
@org.hibernate.search.annotations.Parameter(name = "splitOnNumerics",
value = "0"),
@org.hibernate.search.annotations.Parameter(name = "preserveOriginal",
value = "1")
}
),
@TokenFilterDef(factory = LowerCaseFilterFactory.class)
}
),
{code}
* the content of the field is something like XXXX-AAAA-HAGYU-19910
* if you search for an exact match "XXXX-AAAA-HAGYU-19910" with the
QueryParser, you have a few results: namely the results which have all the different parts
(XXXX, AAAA, HAGYU and 19910) in any order. That's the behaviour I expect considering
my analyzer.
* if you search using the DSL API, you have ALL the results containing at least ONE token
so A LOT of results in our case.
My expectation is that the DSL API should work as the Lucene parser works and it should
return the same results.
The problem is that in ConnectedMultiFieldsTermQueryBuilder, we don't use the
QueryParser to build the Lucene query but a getAllTermsFromText() method which uses the
analyzer to get all the terms and from that we build a OR query.
So when I search for XXXX-AAAA-HAGYU-19910, the DSL API searches for "XXXX" OR
"AAAA" OR "HAGYU" OR "19910".
I really think it's a mistake and that we should use the *QueryParser API to build
the Lucene Query and have the correct behaviour.
If needed, I can provide any further information and/or a test case. I just want to be
sure you consider it a bug before working further on this. Otherwise I'll stick to
using the *QueryParser API.
Thanks for your feedback.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:17 a.m.
New subject: [Hibernate-JIRA] Commented: (HSEARCH-917) DSL API doesn't build the correct Lucene query
[
http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-917?pag...
]
Guillaume Smet commented on HSEARCH-917:
----------------------------------------
Hi Emmanuel,
Thanks for your answer.
Coming from the Solr world before starting working with Hibernate Search 3 years ago, the
WordDelimiterFilterFactory is one of my favorite filters/analyzers.
To answer to your points:
* results are on top *if* sorted by score. I must admit I often sort by name instead of
score (especially in autocomplete features because it's really easier to use but even
often in regular searches) and then the problem is that you can have far too many results.
In our case we had 1000 results for an autocomplete search sorted alphabetically (and no,
I cannot get the top ten results because I sort them by name not by score) and it was
unusable due to the latency.
* considering your ngram point, I understand it but I'm under the impression that the
OR should be an option, not the default choice but I suppose it's too late for that.
Perhaps a .matchingAll[Terms](String text) at the same level as .matching() would be a
good idea? That way, people would see it in their IDE autocomplete choices and they would
think about what they really want to do. I don't know if it's compatible with your
vision of the DSL API.
From my experience with Hibernate Search, a lot of people are mistaken
about how matching() works so it might be a good idea to give them an hint in the API.
I can work on a patch once we agree on how to solve this. I'd like to add edismax
support one day or another so I'm interested in working on this part of the code.
--
Guillaume
DSL API doesn't build the correct Lucene query
----------------------------------------------
Key: HSEARCH-917
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-917
Project: Hibernate Search
Issue Type: Bug
Components: query
Affects Versions: 3.4.1.Final
Reporter: Guillaume Smet
Priority: Critical
Hi,
A bit of context:
We are early adopters of Hibernate Search and we have very few problems with it (except
the @IndexEmbedded problem we helped to fix in 3.4.1, no problem so far).
When the DSL API was introduced, I tried it and I found the problem I describe below. I
decided to use the QueryParser API (and the MultiFieldQueryParser API) as a workaround.
The fact is that:
* we use Hibernate Search in every application we have, now;
* the DSL API is really nice and, as we introduced QueryDSL in our application, we now
use a lot of DSL like API and I would like to be able to use Hibernate Search API too;
* I thought it was a deliberate choice but, recently I found an example so weird, I
can't think it's the wanted behaviour.
So this problem isn't new and it exists since the first version of the DSL API.
Now, the description of the problem:
* we use the following analyzer to index a field in our entity:
{code}
@AnalyzerDef(name = HibernateSearchAnalyzer.TEXT,
tokenizer = @TokenizerDef(factory = WhitespaceTokenizerFactory.class),
filters = {
@TokenFilterDef(factory = ASCIIFoldingFilterFactory.class),
@TokenFilterDef(factory = WordDelimiterFilterFactory.class, params = {
@org.hibernate.search.annotations.Parameter(name =
"generateWordParts", value = "1"),
@org.hibernate.search.annotations.Parameter(name =
"generateNumberParts", value = "1"),
@org.hibernate.search.annotations.Parameter(name = "catenateWords",
value = "0"),
@org.hibernate.search.annotations.Parameter(name = "catenateNumbers",
value = "0"),
@org.hibernate.search.annotations.Parameter(name = "catenateAll",
value = "0"),
@org.hibernate.search.annotations.Parameter(name =
"splitOnCaseChange", value = "0"),
@org.hibernate.search.annotations.Parameter(name = "splitOnNumerics",
value = "0"),
@org.hibernate.search.annotations.Parameter(name = "preserveOriginal",
value = "1")
}
),
@TokenFilterDef(factory = LowerCaseFilterFactory.class)
}
),
{code}
* the content of the field is something like XXXX-AAAA-HAGYU-19910
* if you search for an exact match "XXXX-AAAA-HAGYU-19910" with the
QueryParser, you have a few results: namely the results which have all the different parts
(XXXX, AAAA, HAGYU and 19910) in any order. That's the behaviour I expect considering
my analyzer.
* if you search using the DSL API, you have ALL the results containing at least ONE token
so A LOT of results in our case.
My expectation is that the DSL API should work as the Lucene parser works and it should
return the same results.
The problem is that in ConnectedMultiFieldsTermQueryBuilder, we don't use the
QueryParser to build the Lucene query but a getAllTermsFromText() method which uses the
analyzer to get all the terms and from that we build a OR query.
So when I search for XXXX-AAAA-HAGYU-19910, the DSL API searches for "XXXX" OR
"AAAA" OR "HAGYU" OR "19910".
I really think it's a mistake and that we should use the *QueryParser API to build
the Lucene Query and have the correct behaviour.
If needed, I can provide any further information and/or a test case. I just want to be
sure you consider it a bug before working further on this. Otherwise I'll stick to
using the *QueryParser API.
Thanks for your feedback.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:16 a.m.
New subject: [Hibernate-JIRA] Commented: (HSEARCH-917) DSL API doesn't build the correct Lucene query
[
http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-917?pag...
]
Emmanuel Bernard commented on HSEARCH-917:
------------------------------------------
Interesting, I have always wanted to support auto complete and spell checking natively in
Hibernate Search. The DSL would have a top level construct for that (like keyword, phrase
and soon spatial). For this query we would definitely use AND.
I agree, changing OR to AND would be a breaking move I would be concerned about. Plus I
think it's fine for a bunch of use cases. Do you have other use cases where AND is
better by the way?
On the construct approach, we can do
{code}Query query = builder
.keyword()
.onField( "uuid" )
.matching( "XXXX-AAAA-HAGYU-19910" )
.withAllTerms() //or a better name
.createQuery();
{code}
or as you proposed
{code}Query query = builder
.keyword()
.onField( "uuid" )
.matchingAllOf( "XXXX-AAAA-HAGYU-19910" )
.createQuery();
{code}
Version 1 is definitely more inlined with the DSL design as it stands and will show up in
the IDE autocompletion just the same. I'm also a bit concerned about the vagueness of
option 2 wrt the method name.
We probably should revive HSEARCH-269 in parallel to this effort. If you have some spare
time to work on it that would be awesome too :)
DSL API doesn't build the correct Lucene query
----------------------------------------------
Key: HSEARCH-917
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-917
Project: Hibernate Search
Issue Type: Bug
Components: query
Affects Versions: 3.4.1.Final
Reporter: Guillaume Smet
Priority: Critical
Hi,
A bit of context:
We are early adopters of Hibernate Search and we have very few problems with it (except
the @IndexEmbedded problem we helped to fix in 3.4.1, no problem so far).
When the DSL API was introduced, I tried it and I found the problem I describe below. I
decided to use the QueryParser API (and the MultiFieldQueryParser API) as a workaround.
The fact is that:
* we use Hibernate Search in every application we have, now;
* the DSL API is really nice and, as we introduced QueryDSL in our application, we now
use a lot of DSL like API and I would like to be able to use Hibernate Search API too;
* I thought it was a deliberate choice but, recently I found an example so weird, I
can't think it's the wanted behaviour.
So this problem isn't new and it exists since the first version of the DSL API.
Now, the description of the problem:
* we use the following analyzer to index a field in our entity:
{code}
@AnalyzerDef(name = HibernateSearchAnalyzer.TEXT,
tokenizer = @TokenizerDef(factory = WhitespaceTokenizerFactory.class),
filters = {
@TokenFilterDef(factory = ASCIIFoldingFilterFactory.class),
@TokenFilterDef(factory = WordDelimiterFilterFactory.class, params = {
@org.hibernate.search.annotations.Parameter(name =
"generateWordParts", value = "1"),
@org.hibernate.search.annotations.Parameter(name =
"generateNumberParts", value = "1"),
@org.hibernate.search.annotations.Parameter(name = "catenateWords",
value = "0"),
@org.hibernate.search.annotations.Parameter(name = "catenateNumbers",
value = "0"),
@org.hibernate.search.annotations.Parameter(name = "catenateAll",
value = "0"),
@org.hibernate.search.annotations.Parameter(name =
"splitOnCaseChange", value = "0"),
@org.hibernate.search.annotations.Parameter(name = "splitOnNumerics",
value = "0"),
@org.hibernate.search.annotations.Parameter(name = "preserveOriginal",
value = "1")
}
),
@TokenFilterDef(factory = LowerCaseFilterFactory.class)
}
),
{code}
* the content of the field is something like XXXX-AAAA-HAGYU-19910
* if you search for an exact match "XXXX-AAAA-HAGYU-19910" with the
QueryParser, you have a few results: namely the results which have all the different parts
(XXXX, AAAA, HAGYU and 19910) in any order. That's the behaviour I expect considering
my analyzer.
* if you search using the DSL API, you have ALL the results containing at least ONE token
so A LOT of results in our case.
My expectation is that the DSL API should work as the Lucene parser works and it should
return the same results.
The problem is that in ConnectedMultiFieldsTermQueryBuilder, we don't use the
QueryParser to build the Lucene query but a getAllTermsFromText() method which uses the
analyzer to get all the terms and from that we build a OR query.
So when I search for XXXX-AAAA-HAGYU-19910, the DSL API searches for "XXXX" OR
"AAAA" OR "HAGYU" OR "19910".
I really think it's a mistake and that we should use the *QueryParser API to build
the Lucene Query and have the correct behaviour.
If needed, I can provide any further information and/or a test case. I just want to be
sure you consider it a bug before working further on this. Otherwise I'll stick to
using the *QueryParser API.
Thanks for your feedback.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
3:08 p.m.
New subject: [Hibernate-JIRA] Commented: (HSEARCH-917) DSL API doesn't build the correct Lucene query
[
http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-917?pag...
]
Guillaume Smet commented on HSEARCH-917:
----------------------------------------
bq. Do you have other use cases where AND is better by the way?
Well, in all our applications, we mostly use AND (using the Lucene MultiFieldQueryParser
directly instead of the DSL API).
Probably because I use dismax a lot on our Solr powered search engines. I then use
"minimum should match" to allow for 1 or 2 missing words but having most of them
in the results. AND is more similar to this approach.
bq. and will show up in the IDE autocompletion just the same
Not exactly. With option 2, if you do match<TAB>, you have both choices proposed in
the IDE autocompletion. That's why I prefer this option.
But I don't have a strong opinion about it.
I'll try to work on a patch soon with option 1 in mind. We can change the syntax later
if we find something better.
--
Guillaume
DSL API doesn't build the correct Lucene query
----------------------------------------------
Key: HSEARCH-917
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-917
Project: Hibernate Search
Issue Type: Bug
Components: query
Affects Versions: 3.4.1.Final
Reporter: Guillaume Smet
Priority: Critical
Hi,
A bit of context:
We are early adopters of Hibernate Search and we have very few problems with it (except
the @IndexEmbedded problem we helped to fix in 3.4.1, no problem so far).
When the DSL API was introduced, I tried it and I found the problem I describe below. I
decided to use the QueryParser API (and the MultiFieldQueryParser API) as a workaround.
The fact is that:
* we use Hibernate Search in every application we have, now;
* the DSL API is really nice and, as we introduced QueryDSL in our application, we now
use a lot of DSL like API and I would like to be able to use Hibernate Search API too;
* I thought it was a deliberate choice but, recently I found an example so weird, I
can't think it's the wanted behaviour.
So this problem isn't new and it exists since the first version of the DSL API.
Now, the description of the problem:
* we use the following analyzer to index a field in our entity:
{code}
@AnalyzerDef(name = HibernateSearchAnalyzer.TEXT,
tokenizer = @TokenizerDef(factory = WhitespaceTokenizerFactory.class),
filters = {
@TokenFilterDef(factory = ASCIIFoldingFilterFactory.class),
@TokenFilterDef(factory = WordDelimiterFilterFactory.class, params = {
@org.hibernate.search.annotations.Parameter(name =
"generateWordParts", value = "1"),
@org.hibernate.search.annotations.Parameter(name =
"generateNumberParts", value = "1"),
@org.hibernate.search.annotations.Parameter(name = "catenateWords",
value = "0"),
@org.hibernate.search.annotations.Parameter(name = "catenateNumbers",
value = "0"),
@org.hibernate.search.annotations.Parameter(name = "catenateAll",
value = "0"),
@org.hibernate.search.annotations.Parameter(name =
"splitOnCaseChange", value = "0"),
@org.hibernate.search.annotations.Parameter(name = "splitOnNumerics",
value = "0"),
@org.hibernate.search.annotations.Parameter(name = "preserveOriginal",
value = "1")
}
),
@TokenFilterDef(factory = LowerCaseFilterFactory.class)
}
),
{code}
* the content of the field is something like XXXX-AAAA-HAGYU-19910
* if you search for an exact match "XXXX-AAAA-HAGYU-19910" with the
QueryParser, you have a few results: namely the results which have all the different parts
(XXXX, AAAA, HAGYU and 19910) in any order. That's the behaviour I expect considering
my analyzer.
* if you search using the DSL API, you have ALL the results containing at least ONE token
so A LOT of results in our case.
My expectation is that the DSL API should work as the Lucene parser works and it should
return the same results.
The problem is that in ConnectedMultiFieldsTermQueryBuilder, we don't use the
QueryParser to build the Lucene query but a getAllTermsFromText() method which uses the
analyzer to get all the terms and from that we build a OR query.
So when I search for XXXX-AAAA-HAGYU-19910, the DSL API searches for "XXXX" OR
"AAAA" OR "HAGYU" OR "19910".
I really think it's a mistake and that we should use the *QueryParser API to build
the Lucene Query and have the correct behaviour.
If needed, I can provide any further information and/or a test case. I just want to be
sure you consider it a bug before working further on this. Otherwise I'll stick to
using the *QueryParser API.
Thanks for your feedback.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
3:39 p.m.
New subject: [Hibernate-JIRA] Commented: (HSEARCH-917) DSL API doesn't build the correct Lucene query
[
http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-917?pag...
]
Sanne Grinovero commented on HSEARCH-917:
-----------------------------------------
bq. if you search for an exact match "XXXX-AAAA-HAGYU-19910" with the
QueryParser, you have a few results: namely the results which have all the different parts
(XXXX, AAAA, HAGYU and 19910) in any order. That's the behaviour I expect considering
my analyzer.
The default of Lucene's QueryParser is actually OR as well, including in the case of
the extension MultiFieldQueryParser, so the current DSL is following the same defaults.
You're very welcome to improve the DSL, just make sure you're not having a
different problem.
DSL API doesn't build the correct Lucene query
----------------------------------------------
Key: HSEARCH-917
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-917
Project: Hibernate Search
Issue Type: Bug
Components: query
Affects Versions: 3.4.1.Final
Reporter: Guillaume Smet
Priority: Critical
Hi,
A bit of context:
We are early adopters of Hibernate Search and we have very few problems with it (except
the @IndexEmbedded problem we helped to fix in 3.4.1, no problem so far).
When the DSL API was introduced, I tried it and I found the problem I describe below. I
decided to use the QueryParser API (and the MultiFieldQueryParser API) as a workaround.
The fact is that:
* we use Hibernate Search in every application we have, now;
* the DSL API is really nice and, as we introduced QueryDSL in our application, we now
use a lot of DSL like API and I would like to be able to use Hibernate Search API too;
* I thought it was a deliberate choice but, recently I found an example so weird, I
can't think it's the wanted behaviour.
So this problem isn't new and it exists since the first version of the DSL API.
Now, the description of the problem:
* we use the following analyzer to index a field in our entity:
{code}
@AnalyzerDef(name = HibernateSearchAnalyzer.TEXT,
tokenizer = @TokenizerDef(factory = WhitespaceTokenizerFactory.class),
filters = {
@TokenFilterDef(factory = ASCIIFoldingFilterFactory.class),
@TokenFilterDef(factory = WordDelimiterFilterFactory.class, params = {
@org.hibernate.search.annotations.Parameter(name =
"generateWordParts", value = "1"),
@org.hibernate.search.annotations.Parameter(name =
"generateNumberParts", value = "1"),
@org.hibernate.search.annotations.Parameter(name = "catenateWords",
value = "0"),
@org.hibernate.search.annotations.Parameter(name = "catenateNumbers",
value = "0"),
@org.hibernate.search.annotations.Parameter(name = "catenateAll",
value = "0"),
@org.hibernate.search.annotations.Parameter(name =
"splitOnCaseChange", value = "0"),
@org.hibernate.search.annotations.Parameter(name = "splitOnNumerics",
value = "0"),
@org.hibernate.search.annotations.Parameter(name = "preserveOriginal",
value = "1")
}
),
@TokenFilterDef(factory = LowerCaseFilterFactory.class)
}
),
{code}
* the content of the field is something like XXXX-AAAA-HAGYU-19910
* if you search for an exact match "XXXX-AAAA-HAGYU-19910" with the
QueryParser, you have a few results: namely the results which have all the different parts
(XXXX, AAAA, HAGYU and 19910) in any order. That's the behaviour I expect considering
my analyzer.
* if you search using the DSL API, you have ALL the results containing at least ONE token
so A LOT of results in our case.
My expectation is that the DSL API should work as the Lucene parser works and it should
return the same results.
The problem is that in ConnectedMultiFieldsTermQueryBuilder, we don't use the
QueryParser to build the Lucene query but a getAllTermsFromText() method which uses the
analyzer to get all the terms and from that we build a OR query.
So when I search for XXXX-AAAA-HAGYU-19910, the DSL API searches for "XXXX" OR
"AAAA" OR "HAGYU" OR "19910".
I really think it's a mistake and that we should use the *QueryParser API to build
the Lucene Query and have the correct behaviour.
If needed, I can provide any further information and/or a test case. I just want to be
sure you consider it a bug before working further on this. Otherwise I'll stick to
using the *QueryParser API.
Thanks for your feedback.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:16 p.m.
New subject: [Hibernate-JIRA] Commented: (HSEARCH-917) DSL API doesn't build the correct Lucene query
[
http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-917?pag...
]
Guillaume Smet commented on HSEARCH-917:
----------------------------------------
Yes, you're right. I have a wrapper which switches it to AND automatically.
I don't think I have the right to change the name of this issue. Could you rename it
to "Add AND operator support in the DSL API" or something similar?
Thanks.
DSL API doesn't build the correct Lucene query
----------------------------------------------
Key: HSEARCH-917
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-917
Project: Hibernate Search
Issue Type: Bug
Components: query
Affects Versions: 3.4.1.Final
Reporter: Guillaume Smet
Priority: Critical
Hi,
A bit of context:
We are early adopters of Hibernate Search and we have very few problems with it (except
the @IndexEmbedded problem we helped to fix in 3.4.1, no problem so far).
When the DSL API was introduced, I tried it and I found the problem I describe below. I
decided to use the QueryParser API (and the MultiFieldQueryParser API) as a workaround.
The fact is that:
* we use Hibernate Search in every application we have, now;
* the DSL API is really nice and, as we introduced QueryDSL in our application, we now
use a lot of DSL like API and I would like to be able to use Hibernate Search API too;
* I thought it was a deliberate choice but, recently I found an example so weird, I
can't think it's the wanted behaviour.
So this problem isn't new and it exists since the first version of the DSL API.
Now, the description of the problem:
* we use the following analyzer to index a field in our entity:
{code}
@AnalyzerDef(name = HibernateSearchAnalyzer.TEXT,
tokenizer = @TokenizerDef(factory = WhitespaceTokenizerFactory.class),
filters = {
@TokenFilterDef(factory = ASCIIFoldingFilterFactory.class),
@TokenFilterDef(factory = WordDelimiterFilterFactory.class, params = {
@org.hibernate.search.annotations.Parameter(name =
"generateWordParts", value = "1"),
@org.hibernate.search.annotations.Parameter(name =
"generateNumberParts", value = "1"),
@org.hibernate.search.annotations.Parameter(name = "catenateWords",
value = "0"),
@org.hibernate.search.annotations.Parameter(name = "catenateNumbers",
value = "0"),
@org.hibernate.search.annotations.Parameter(name = "catenateAll",
value = "0"),
@org.hibernate.search.annotations.Parameter(name =
"splitOnCaseChange", value = "0"),
@org.hibernate.search.annotations.Parameter(name = "splitOnNumerics",
value = "0"),
@org.hibernate.search.annotations.Parameter(name = "preserveOriginal",
value = "1")
}
),
@TokenFilterDef(factory = LowerCaseFilterFactory.class)
}
),
{code}
* the content of the field is something like XXXX-AAAA-HAGYU-19910
* if you search for an exact match "XXXX-AAAA-HAGYU-19910" with the
QueryParser, you have a few results: namely the results which have all the different parts
(XXXX, AAAA, HAGYU and 19910) in any order. That's the behaviour I expect considering
my analyzer.
* if you search using the DSL API, you have ALL the results containing at least ONE token
so A LOT of results in our case.
My expectation is that the DSL API should work as the Lucene parser works and it should
return the same results.
The problem is that in ConnectedMultiFieldsTermQueryBuilder, we don't use the
QueryParser to build the Lucene query but a getAllTermsFromText() method which uses the
analyzer to get all the terms and from that we build a OR query.
So when I search for XXXX-AAAA-HAGYU-19910, the DSL API searches for "XXXX" OR
"AAAA" OR "HAGYU" OR "19910".
I really think it's a mistake and that we should use the *QueryParser API to build
the Lucene Query and have the correct behaviour.
If needed, I can provide any further information and/or a test case. I just want to be
sure you consider it a bug before working further on this. Otherwise I'll stick to
using the *QueryParser API.
Thanks for your feedback.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
5 p.m.
New subject: [Hibernate-JIRA] Updated: (HSEARCH-917) Add AND operator support in the DSL API
[
http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-917?pag...
]
Sanne Grinovero updated HSEARCH-917:
------------------------------------
Suitable for new contributors: [Yes, likely]
Affects Version/s: (was: 3.4.1.Final)
Issue Type: Improvement (was: Bug)
Summary: Add AND operator support in the DSL API (was: DSL API
doesn't build the correct Lucene query)
Add AND operator support in the DSL API
---------------------------------------
Key: HSEARCH-917
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-917
Project: Hibernate Search
Issue Type: Improvement
Components: query
Reporter: Guillaume Smet
Priority: Critical
Hi,
A bit of context:
We are early adopters of Hibernate Search and we have very few problems with it (except
the @IndexEmbedded problem we helped to fix in 3.4.1, no problem so far).
When the DSL API was introduced, I tried it and I found the problem I describe below. I
decided to use the QueryParser API (and the MultiFieldQueryParser API) as a workaround.
The fact is that:
* we use Hibernate Search in every application we have, now;
* the DSL API is really nice and, as we introduced QueryDSL in our application, we now
use a lot of DSL like API and I would like to be able to use Hibernate Search API too;
* I thought it was a deliberate choice but, recently I found an example so weird, I
can't think it's the wanted behaviour.
So this problem isn't new and it exists since the first version of the DSL API.
Now, the description of the problem:
* we use the following analyzer to index a field in our entity:
{code}
@AnalyzerDef(name = HibernateSearchAnalyzer.TEXT,
tokenizer = @TokenizerDef(factory = WhitespaceTokenizerFactory.class),
filters = {
@TokenFilterDef(factory = ASCIIFoldingFilterFactory.class),
@TokenFilterDef(factory = WordDelimiterFilterFactory.class, params = {
@org.hibernate.search.annotations.Parameter(name =
"generateWordParts", value = "1"),
@org.hibernate.search.annotations.Parameter(name =
"generateNumberParts", value = "1"),
@org.hibernate.search.annotations.Parameter(name = "catenateWords",
value = "0"),
@org.hibernate.search.annotations.Parameter(name = "catenateNumbers",
value = "0"),
@org.hibernate.search.annotations.Parameter(name = "catenateAll",
value = "0"),
@org.hibernate.search.annotations.Parameter(name =
"splitOnCaseChange", value = "0"),
@org.hibernate.search.annotations.Parameter(name = "splitOnNumerics",
value = "0"),
@org.hibernate.search.annotations.Parameter(name = "preserveOriginal",
value = "1")
}
),
@TokenFilterDef(factory = LowerCaseFilterFactory.class)
}
),
{code}
* the content of the field is something like XXXX-AAAA-HAGYU-19910
* if you search for an exact match "XXXX-AAAA-HAGYU-19910" with the
QueryParser, you have a few results: namely the results which have all the different parts
(XXXX, AAAA, HAGYU and 19910) in any order. That's the behaviour I expect considering
my analyzer.
* if you search using the DSL API, you have ALL the results containing at least ONE token
so A LOT of results in our case.
My expectation is that the DSL API should work as the Lucene parser works and it should
return the same results.
The problem is that in ConnectedMultiFieldsTermQueryBuilder, we don't use the
QueryParser to build the Lucene query but a getAllTermsFromText() method which uses the
analyzer to get all the terms and from that we build a OR query.
So when I search for XXXX-AAAA-HAGYU-19910, the DSL API searches for "XXXX" OR
"AAAA" OR "HAGYU" OR "19910".
I really think it's a mistake and that we should use the *QueryParser API to build
the Lucene Query and have the correct behaviour.
If needed, I can provide any further information and/or a test case. I just want to be
sure you consider it a bug before working further on this. Otherwise I'll stick to
using the *QueryParser API.
Thanks for your feedback.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:03 p.m.
New subject: [Hibernate-JIRA] Assigned: (HSEARCH-917) Add AND operator support in the DSL API
[
http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-917?pag...
]
Sanne Grinovero reassigned HSEARCH-917:
---------------------------------------
Assignee: Guillaume Smet
Add AND operator support in the DSL API
---------------------------------------
Key: HSEARCH-917
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-917
Project: Hibernate Search
Issue Type: Improvement
Components: query
Reporter: Guillaume Smet
Assignee: Guillaume Smet
Priority: Critical
Hi,
A bit of context:
We are early adopters of Hibernate Search and we have very few problems with it (except
the @IndexEmbedded problem we helped to fix in 3.4.1, no problem so far).
When the DSL API was introduced, I tried it and I found the problem I describe below. I
decided to use the QueryParser API (and the MultiFieldQueryParser API) as a workaround.
The fact is that:
* we use Hibernate Search in every application we have, now;
* the DSL API is really nice and, as we introduced QueryDSL in our application, we now
use a lot of DSL like API and I would like to be able to use Hibernate Search API too;
* I thought it was a deliberate choice but, recently I found an example so weird, I
can't think it's the wanted behaviour.
So this problem isn't new and it exists since the first version of the DSL API.
Now, the description of the problem:
* we use the following analyzer to index a field in our entity:
{code}
@AnalyzerDef(name = HibernateSearchAnalyzer.TEXT,
tokenizer = @TokenizerDef(factory = WhitespaceTokenizerFactory.class),
filters = {
@TokenFilterDef(factory = ASCIIFoldingFilterFactory.class),
@TokenFilterDef(factory = WordDelimiterFilterFactory.class, params = {
@org.hibernate.search.annotations.Parameter(name =
"generateWordParts", value = "1"),
@org.hibernate.search.annotations.Parameter(name =
"generateNumberParts", value = "1"),
@org.hibernate.search.annotations.Parameter(name = "catenateWords",
value = "0"),
@org.hibernate.search.annotations.Parameter(name = "catenateNumbers",
value = "0"),
@org.hibernate.search.annotations.Parameter(name = "catenateAll",
value = "0"),
@org.hibernate.search.annotations.Parameter(name =
"splitOnCaseChange", value = "0"),
@org.hibernate.search.annotations.Parameter(name = "splitOnNumerics",
value = "0"),
@org.hibernate.search.annotations.Parameter(name = "preserveOriginal",
value = "1")
}
),
@TokenFilterDef(factory = LowerCaseFilterFactory.class)
}
),
{code}
* the content of the field is something like XXXX-AAAA-HAGYU-19910
* if you search for an exact match "XXXX-AAAA-HAGYU-19910" with the
QueryParser, you have a few results: namely the results which have all the different parts
(XXXX, AAAA, HAGYU and 19910) in any order. That's the behaviour I expect considering
my analyzer.
* if you search using the DSL API, you have ALL the results containing at least ONE token
so A LOT of results in our case.
My expectation is that the DSL API should work as the Lucene parser works and it should
return the same results.
The problem is that in ConnectedMultiFieldsTermQueryBuilder, we don't use the
QueryParser to build the Lucene query but a getAllTermsFromText() method which uses the
analyzer to get all the terms and from that we build a OR query.
So when I search for XXXX-AAAA-HAGYU-19910, the DSL API searches for "XXXX" OR
"AAAA" OR "HAGYU" OR "19910".
I really think it's a mistake and that we should use the *QueryParser API to build
the Lucene Query and have the correct behaviour.
If needed, I can provide any further information and/or a test case. I just want to be
sure you consider it a bug before working further on this. Otherwise I'll stick to
using the *QueryParser API.
Thanks for your feedback.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:05 p.m.
New subject: [Hibernate-JIRA] Commented: (HSEARCH-917) Add AND operator support in the DSL API
[
http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-917?pag...
]
Sanne Grinovero commented on HSEARCH-917:
-----------------------------------------
Changed title, issue type to "Improvement" rather than bug and improved your
permissions ;)
Cheers
Add AND operator support in the DSL API
---------------------------------------
Key: HSEARCH-917
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-917
Project: Hibernate Search
Issue Type: Improvement
Components: query
Reporter: Guillaume Smet
Assignee: Guillaume Smet
Priority: Critical
Hi,
A bit of context:
We are early adopters of Hibernate Search and we have very few problems with it (except
the @IndexEmbedded problem we helped to fix in 3.4.1, no problem so far).
When the DSL API was introduced, I tried it and I found the problem I describe below. I
decided to use the QueryParser API (and the MultiFieldQueryParser API) as a workaround.
The fact is that:
* we use Hibernate Search in every application we have, now;
* the DSL API is really nice and, as we introduced QueryDSL in our application, we now
use a lot of DSL like API and I would like to be able to use Hibernate Search API too;
* I thought it was a deliberate choice but, recently I found an example so weird, I
can't think it's the wanted behaviour.
So this problem isn't new and it exists since the first version of the DSL API.
Now, the description of the problem:
* we use the following analyzer to index a field in our entity:
{code}
@AnalyzerDef(name = HibernateSearchAnalyzer.TEXT,
tokenizer = @TokenizerDef(factory = WhitespaceTokenizerFactory.class),
filters = {
@TokenFilterDef(factory = ASCIIFoldingFilterFactory.class),
@TokenFilterDef(factory = WordDelimiterFilterFactory.class, params = {
@org.hibernate.search.annotations.Parameter(name =
"generateWordParts", value = "1"),
@org.hibernate.search.annotations.Parameter(name =
"generateNumberParts", value = "1"),
@org.hibernate.search.annotations.Parameter(name = "catenateWords",
value = "0"),
@org.hibernate.search.annotations.Parameter(name = "catenateNumbers",
value = "0"),
@org.hibernate.search.annotations.Parameter(name = "catenateAll",
value = "0"),
@org.hibernate.search.annotations.Parameter(name =
"splitOnCaseChange", value = "0"),
@org.hibernate.search.annotations.Parameter(name = "splitOnNumerics",
value = "0"),
@org.hibernate.search.annotations.Parameter(name = "preserveOriginal",
value = "1")
}
),
@TokenFilterDef(factory = LowerCaseFilterFactory.class)
}
),
{code}
* the content of the field is something like XXXX-AAAA-HAGYU-19910
* if you search for an exact match "XXXX-AAAA-HAGYU-19910" with the
QueryParser, you have a few results: namely the results which have all the different parts
(XXXX, AAAA, HAGYU and 19910) in any order. That's the behaviour I expect considering
my analyzer.
* if you search using the DSL API, you have ALL the results containing at least ONE token
so A LOT of results in our case.
My expectation is that the DSL API should work as the Lucene parser works and it should
return the same results.
The problem is that in ConnectedMultiFieldsTermQueryBuilder, we don't use the
QueryParser to build the Lucene query but a getAllTermsFromText() method which uses the
analyzer to get all the terms and from that we build a OR query.
So when I search for XXXX-AAAA-HAGYU-19910, the DSL API searches for "XXXX" OR
"AAAA" OR "HAGYU" OR "19910".
I really think it's a mistake and that we should use the *QueryParser API to build
the Lucene Query and have the correct behaviour.
If needed, I can provide any further information and/or a test case. I just want to be
sure you consider it a bug before working further on this. Otherwise I'll stick to
using the *QueryParser API.
Thanks for your feedback.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
3:45 a.m.
New subject: [Hibernate-JIRA] Updated: (HSEARCH-917) Add match all terms option when matching in the DSL API
[
http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-917?pag...
]
Emmanuel Bernard updated HSEARCH-917:
-------------------------------------
Fix Version/s: 4.1
Summary: Add match all terms option when matching in the DSL API (was: Add AND
operator support in the DSL API)
Add match all terms option when matching in the DSL API
-------------------------------------------------------
Key: HSEARCH-917
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-917
Project: Hibernate Search
Issue Type: Improvement
Components: query
Reporter: Guillaume Smet
Assignee: Guillaume Smet
Priority: Critical
Fix For: 4.1
Hi,
A bit of context:
We are early adopters of Hibernate Search and we have very few problems with it (except
the @IndexEmbedded problem we helped to fix in 3.4.1, no problem so far).
When the DSL API was introduced, I tried it and I found the problem I describe below. I
decided to use the QueryParser API (and the MultiFieldQueryParser API) as a workaround.
The fact is that:
* we use Hibernate Search in every application we have, now;
* the DSL API is really nice and, as we introduced QueryDSL in our application, we now
use a lot of DSL like API and I would like to be able to use Hibernate Search API too;
* I thought it was a deliberate choice but, recently I found an example so weird, I
can't think it's the wanted behaviour.
So this problem isn't new and it exists since the first version of the DSL API.
Now, the description of the problem:
* we use the following analyzer to index a field in our entity:
{code}
@AnalyzerDef(name = HibernateSearchAnalyzer.TEXT,
tokenizer = @TokenizerDef(factory = WhitespaceTokenizerFactory.class),
filters = {
@TokenFilterDef(factory = ASCIIFoldingFilterFactory.class),
@TokenFilterDef(factory = WordDelimiterFilterFactory.class, params = {
@org.hibernate.search.annotations.Parameter(name =
"generateWordParts", value = "1"),
@org.hibernate.search.annotations.Parameter(name =
"generateNumberParts", value = "1"),
@org.hibernate.search.annotations.Parameter(name = "catenateWords",
value = "0"),
@org.hibernate.search.annotations.Parameter(name = "catenateNumbers",
value = "0"),
@org.hibernate.search.annotations.Parameter(name = "catenateAll",
value = "0"),
@org.hibernate.search.annotations.Parameter(name =
"splitOnCaseChange", value = "0"),
@org.hibernate.search.annotations.Parameter(name = "splitOnNumerics",
value = "0"),
@org.hibernate.search.annotations.Parameter(name = "preserveOriginal",
value = "1")
}
),
@TokenFilterDef(factory = LowerCaseFilterFactory.class)
}
),
{code}
* the content of the field is something like XXXX-AAAA-HAGYU-19910
* if you search for an exact match "XXXX-AAAA-HAGYU-19910" with the
QueryParser, you have a few results: namely the results which have all the different parts
(XXXX, AAAA, HAGYU and 19910) in any order. That's the behaviour I expect considering
my analyzer.
* if you search using the DSL API, you have ALL the results containing at least ONE token
so A LOT of results in our case.
My expectation is that the DSL API should work as the Lucene parser works and it should
return the same results.
The problem is that in ConnectedMultiFieldsTermQueryBuilder, we don't use the
QueryParser to build the Lucene query but a getAllTermsFromText() method which uses the
analyzer to get all the terms and from that we build a OR query.
So when I search for XXXX-AAAA-HAGYU-19910, the DSL API searches for "XXXX" OR
"AAAA" OR "HAGYU" OR "19910".
I really think it's a mistake and that we should use the *QueryParser API to build
the Lucene Query and have the correct behaviour.
If needed, I can provide any further information and/or a test case. I just want to be
sure you consider it a bug before working further on this. Otherwise I'll stick to
using the *QueryParser API.
Thanks for your feedback.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:54 a.m.
New subject: [Hibernate-JIRA] Updated: (HSEARCH-917) Add match all terms option when matching in the DSL API
[
https://hibernate.onjira.com/browse/HSEARCH-917?page=com.atlassian.jira.p...
]
Sanne Grinovero updated HSEARCH-917:
------------------------------------
Fix Version/s: (was: 4.1)
Add match all terms option when matching in the DSL API
-------------------------------------------------------
Key: HSEARCH-917
URL: https://hibernate.onjira.com/browse/HSEARCH-917
Project: Hibernate Search
Issue Type: Improvement
Components: query
Reporter: Guillaume Smet
Assignee: Guillaume Smet
Priority: Critical
Hi,
A bit of context:
We are early adopters of Hibernate Search and we have very few problems with it (except
the @IndexEmbedded problem we helped to fix in 3.4.1, no problem so far).
When the DSL API was introduced, I tried it and I found the problem I describe below. I
decided to use the QueryParser API (and the MultiFieldQueryParser API) as a workaround.
The fact is that:
* we use Hibernate Search in every application we have, now;
* the DSL API is really nice and, as we introduced QueryDSL in our application, we now
use a lot of DSL like API and I would like to be able to use Hibernate Search API too;
* I thought it was a deliberate choice but, recently I found an example so weird, I
can't think it's the wanted behaviour.
So this problem isn't new and it exists since the first version of the DSL API.
Now, the description of the problem:
* we use the following analyzer to index a field in our entity:
{code}
@AnalyzerDef(name = HibernateSearchAnalyzer.TEXT,
tokenizer = @TokenizerDef(factory = WhitespaceTokenizerFactory.class),
filters = {
@TokenFilterDef(factory = ASCIIFoldingFilterFactory.class),
@TokenFilterDef(factory = WordDelimiterFilterFactory.class, params = {
@org.hibernate.search.annotations.Parameter(name =
"generateWordParts", value = "1"),
@org.hibernate.search.annotations.Parameter(name =
"generateNumberParts", value = "1"),
@org.hibernate.search.annotations.Parameter(name = "catenateWords",
value = "0"),
@org.hibernate.search.annotations.Parameter(name = "catenateNumbers",
value = "0"),
@org.hibernate.search.annotations.Parameter(name = "catenateAll",
value = "0"),
@org.hibernate.search.annotations.Parameter(name =
"splitOnCaseChange", value = "0"),
@org.hibernate.search.annotations.Parameter(name = "splitOnNumerics",
value = "0"),
@org.hibernate.search.annotations.Parameter(name = "preserveOriginal",
value = "1")
}
),
@TokenFilterDef(factory = LowerCaseFilterFactory.class)
}
),
{code}
* the content of the field is something like XXXX-AAAA-HAGYU-19910
* if you search for an exact match "XXXX-AAAA-HAGYU-19910" with the
QueryParser, you have a few results: namely the results which have all the different parts
(XXXX, AAAA, HAGYU and 19910) in any order. That's the behaviour I expect considering
my analyzer.
* if you search using the DSL API, you have ALL the results containing at least ONE token
so A LOT of results in our case.
My expectation is that the DSL API should work as the Lucene parser works and it should
return the same results.
The problem is that in ConnectedMultiFieldsTermQueryBuilder, we don't use the
QueryParser to build the Lucene query but a getAllTermsFromText() method which uses the
analyzer to get all the terms and from that we build a OR query.
So when I search for XXXX-AAAA-HAGYU-19910, the DSL API searches for "XXXX" OR
"AAAA" OR "HAGYU" OR "19910".
I really think it's a mistake and that we should use the *QueryParser API to build
the Lucene Query and have the correct behaviour.
If needed, I can provide any further information and/or a test case. I just want to be
sure you consider it a bug before working further on this. Otherwise I'll stick to
using the *QueryParser API.
Thanks for your feedback.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
4 p.m.
New subject: [Hibernate-JIRA] Commented: (HSEARCH-917) Add match all terms option when matching in the DSL API
[
https://hibernate.onjira.com/browse/HSEARCH-917?page=com.atlassian.jira.p...
]
Piotr Jagielski commented on HSEARCH-917:
-----------------------------------------
I would also be interested in this feature.
Add match all terms option when matching in the DSL API
-------------------------------------------------------
Key: HSEARCH-917
URL: https://hibernate.onjira.com/browse/HSEARCH-917
Project: Hibernate Search
Issue Type: Improvement
Components: query
Reporter: Guillaume Smet
Assignee: Guillaume Smet
Priority: Critical
Hi,
A bit of context:
We are early adopters of Hibernate Search and we have very few problems with it (except
the @IndexEmbedded problem we helped to fix in 3.4.1, no problem so far).
When the DSL API was introduced, I tried it and I found the problem I describe below. I
decided to use the QueryParser API (and the MultiFieldQueryParser API) as a workaround.
The fact is that:
* we use Hibernate Search in every application we have, now;
* the DSL API is really nice and, as we introduced QueryDSL in our application, we now
use a lot of DSL like API and I would like to be able to use Hibernate Search API too;
* I thought it was a deliberate choice but, recently I found an example so weird, I
can't think it's the wanted behaviour.
So this problem isn't new and it exists since the first version of the DSL API.
Now, the description of the problem:
* we use the following analyzer to index a field in our entity:
{code}
@AnalyzerDef(name = HibernateSearchAnalyzer.TEXT,
tokenizer = @TokenizerDef(factory = WhitespaceTokenizerFactory.class),
filters = {
@TokenFilterDef(factory = ASCIIFoldingFilterFactory.class),
@TokenFilterDef(factory = WordDelimiterFilterFactory.class, params = {
@org.hibernate.search.annotations.Parameter(name =
"generateWordParts", value = "1"),
@org.hibernate.search.annotations.Parameter(name =
"generateNumberParts", value = "1"),
@org.hibernate.search.annotations.Parameter(name = "catenateWords",
value = "0"),
@org.hibernate.search.annotations.Parameter(name = "catenateNumbers",
value = "0"),
@org.hibernate.search.annotations.Parameter(name = "catenateAll",
value = "0"),
@org.hibernate.search.annotations.Parameter(name =
"splitOnCaseChange", value = "0"),
@org.hibernate.search.annotations.Parameter(name = "splitOnNumerics",
value = "0"),
@org.hibernate.search.annotations.Parameter(name = "preserveOriginal",
value = "1")
}
),
@TokenFilterDef(factory = LowerCaseFilterFactory.class)
}
),
{code}
* the content of the field is something like XXXX-AAAA-HAGYU-19910
* if you search for an exact match "XXXX-AAAA-HAGYU-19910" with the
QueryParser, you have a few results: namely the results which have all the different parts
(XXXX, AAAA, HAGYU and 19910) in any order. That's the behaviour I expect considering
my analyzer.
* if you search using the DSL API, you have ALL the results containing at least ONE token
so A LOT of results in our case.
My expectation is that the DSL API should work as the Lucene parser works and it should
return the same results.
The problem is that in ConnectedMultiFieldsTermQueryBuilder, we don't use the
QueryParser to build the Lucene query but a getAllTermsFromText() method which uses the
analyzer to get all the terms and from that we build a OR query.
So when I search for XXXX-AAAA-HAGYU-19910, the DSL API searches for "XXXX" OR
"AAAA" OR "HAGYU" OR "19910".
I really think it's a mistake and that we should use the *QueryParser API to build
the Lucene Query and have the correct behaviour.
If needed, I can provide any further information and/or a test case. I just want to be
sure you consider it a bug before working further on this. Otherwise I'll stick to
using the *QueryParser API.
Thanks for your feedback.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:13 a.m.
New subject: [Hibernate-JIRA] Commented: (HSEARCH-917) Add match all terms option when matching in the DSL API
[
https://hibernate.onjira.com/browse/HSEARCH-917?page=com.atlassian.jira.p...
]
Sanne Grinovero commented on HSEARCH-917:
-----------------------------------------
I think this patch would be relatively easy, but requires a nice test .. it would be great
if someone could contribute it?
I'm of course willing to provide needed pointers and help integrating it.
Add match all terms option when matching in the DSL API
-------------------------------------------------------
Key: HSEARCH-917
URL: https://hibernate.onjira.com/browse/HSEARCH-917
Project: Hibernate Search
Issue Type: Improvement
Components: query
Reporter: Guillaume Smet
Assignee: Guillaume Smet
Priority: Critical
Hi,
A bit of context:
We are early adopters of Hibernate Search and we have very few problems with it (except
the @IndexEmbedded problem we helped to fix in 3.4.1, no problem so far).
When the DSL API was introduced, I tried it and I found the problem I describe below. I
decided to use the QueryParser API (and the MultiFieldQueryParser API) as a workaround.
The fact is that:
* we use Hibernate Search in every application we have, now;
* the DSL API is really nice and, as we introduced QueryDSL in our application, we now
use a lot of DSL like API and I would like to be able to use Hibernate Search API too;
* I thought it was a deliberate choice but, recently I found an example so weird, I
can't think it's the wanted behaviour.
So this problem isn't new and it exists since the first version of the DSL API.
Now, the description of the problem:
* we use the following analyzer to index a field in our entity:
{code}
@AnalyzerDef(name = HibernateSearchAnalyzer.TEXT,
tokenizer = @TokenizerDef(factory = WhitespaceTokenizerFactory.class),
filters = {
@TokenFilterDef(factory = ASCIIFoldingFilterFactory.class),
@TokenFilterDef(factory = WordDelimiterFilterFactory.class, params = {
@org.hibernate.search.annotations.Parameter(name =
"generateWordParts", value = "1"),
@org.hibernate.search.annotations.Parameter(name =
"generateNumberParts", value = "1"),
@org.hibernate.search.annotations.Parameter(name = "catenateWords",
value = "0"),
@org.hibernate.search.annotations.Parameter(name = "catenateNumbers",
value = "0"),
@org.hibernate.search.annotations.Parameter(name = "catenateAll",
value = "0"),
@org.hibernate.search.annotations.Parameter(name =
"splitOnCaseChange", value = "0"),
@org.hibernate.search.annotations.Parameter(name = "splitOnNumerics",
value = "0"),
@org.hibernate.search.annotations.Parameter(name = "preserveOriginal",
value = "1")
}
),
@TokenFilterDef(factory = LowerCaseFilterFactory.class)
}
),
{code}
* the content of the field is something like XXXX-AAAA-HAGYU-19910
* if you search for an exact match "XXXX-AAAA-HAGYU-19910" with the
QueryParser, you have a few results: namely the results which have all the different parts
(XXXX, AAAA, HAGYU and 19910) in any order. That's the behaviour I expect considering
my analyzer.
* if you search using the DSL API, you have ALL the results containing at least ONE token
so A LOT of results in our case.
My expectation is that the DSL API should work as the Lucene parser works and it should
return the same results.
The problem is that in ConnectedMultiFieldsTermQueryBuilder, we don't use the
QueryParser to build the Lucene query but a getAllTermsFromText() method which uses the
analyzer to get all the terms and from that we build a OR query.
So when I search for XXXX-AAAA-HAGYU-19910, the DSL API searches for "XXXX" OR
"AAAA" OR "HAGYU" OR "19910".
I really think it's a mistake and that we should use the *QueryParser API to build
the Lucene Query and have the correct behaviour.
If needed, I can provide any further information and/or a test case. I just want to be
sure you consider it a bug before working further on this. Otherwise I'll stick to
using the *QueryParser API.
Thanks for your feedback.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:44 a.m.
New subject: [Hibernate-JIRA] Commented: (HSEARCH-917) Add match all terms option when matching in the DSL API
[
https://hibernate.onjira.com/browse/HSEARCH-917?page=com.atlassian.jira.p...
]
Guillaume Smet commented on HSEARCH-917:
----------------------------------------
Hi Sanne,
The Hibernate Search part is easy - and I already have it somewhere - but the Lucene one
isn't that easy, depending on your analyzers.
I had to put it on hold for the time being as I have to concentrate my efforts on another
project. I'll be back on it as soon as I've finished my other project (should be
end of june) if noone beats me to it.
--
Guillaume
Add match all terms option when matching in the DSL API
-------------------------------------------------------
Key: HSEARCH-917
URL: https://hibernate.onjira.com/browse/HSEARCH-917
Project: Hibernate Search
Issue Type: Improvement
Components: query
Reporter: Guillaume Smet
Assignee: Guillaume Smet
Priority: Critical
Hi,
A bit of context:
We are early adopters of Hibernate Search and we have very few problems with it (except
the @IndexEmbedded problem we helped to fix in 3.4.1, no problem so far).
When the DSL API was introduced, I tried it and I found the problem I describe below. I
decided to use the QueryParser API (and the MultiFieldQueryParser API) as a workaround.
The fact is that:
* we use Hibernate Search in every application we have, now;
* the DSL API is really nice and, as we introduced QueryDSL in our application, we now
use a lot of DSL like API and I would like to be able to use Hibernate Search API too;
* I thought it was a deliberate choice but, recently I found an example so weird, I
can't think it's the wanted behaviour.
So this problem isn't new and it exists since the first version of the DSL API.
Now, the description of the problem:
* we use the following analyzer to index a field in our entity:
{code}
@AnalyzerDef(name = HibernateSearchAnalyzer.TEXT,
tokenizer = @TokenizerDef(factory = WhitespaceTokenizerFactory.class),
filters = {
@TokenFilterDef(factory = ASCIIFoldingFilterFactory.class),
@TokenFilterDef(factory = WordDelimiterFilterFactory.class, params = {
@org.hibernate.search.annotations.Parameter(name =
"generateWordParts", value = "1"),
@org.hibernate.search.annotations.Parameter(name =
"generateNumberParts", value = "1"),
@org.hibernate.search.annotations.Parameter(name = "catenateWords",
value = "0"),
@org.hibernate.search.annotations.Parameter(name = "catenateNumbers",
value = "0"),
@org.hibernate.search.annotations.Parameter(name = "catenateAll",
value = "0"),
@org.hibernate.search.annotations.Parameter(name =
"splitOnCaseChange", value = "0"),
@org.hibernate.search.annotations.Parameter(name = "splitOnNumerics",
value = "0"),
@org.hibernate.search.annotations.Parameter(name = "preserveOriginal",
value = "1")
}
),
@TokenFilterDef(factory = LowerCaseFilterFactory.class)
}
),
{code}
* the content of the field is something like XXXX-AAAA-HAGYU-19910
* if you search for an exact match "XXXX-AAAA-HAGYU-19910" with the
QueryParser, you have a few results: namely the results which have all the different parts
(XXXX, AAAA, HAGYU and 19910) in any order. That's the behaviour I expect considering
my analyzer.
* if you search using the DSL API, you have ALL the results containing at least ONE token
so A LOT of results in our case.
My expectation is that the DSL API should work as the Lucene parser works and it should
return the same results.
The problem is that in ConnectedMultiFieldsTermQueryBuilder, we don't use the
QueryParser to build the Lucene query but a getAllTermsFromText() method which uses the
analyzer to get all the terms and from that we build a OR query.
So when I search for XXXX-AAAA-HAGYU-19910, the DSL API searches for "XXXX" OR
"AAAA" OR "HAGYU" OR "19910".
I really think it's a mistake and that we should use the *QueryParser API to build
the Lucene Query and have the correct behaviour.
If needed, I can provide any further information and/or a test case. I just want to be
sure you consider it a bug before working further on this. Otherwise I'll stick to
using the *QueryParser API.
Thanks for your feedback.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:22 a.m.
New subject: [Hibernate-JIRA] Commented: (HSEARCH-917) Add match all terms option when matching in the DSL API
[
https://hibernate.onjira.com/browse/HSEARCH-917?page=com.atlassian.jira.p...
]
Sanne Grinovero commented on HSEARCH-917:
-----------------------------------------
Hi Guillaume,
thanks! We can split tasks if you happen to find the time to contribute your draft, as for
my mind the most valuable contribution is the tests and the requirements expressed in
Java. Otherwise looking forward to you finish your other project.
Add match all terms option when matching in the DSL API
-------------------------------------------------------
Key: HSEARCH-917
URL: https://hibernate.onjira.com/browse/HSEARCH-917
Project: Hibernate Search
Issue Type: Improvement
Components: query
Reporter: Guillaume Smet
Assignee: Guillaume Smet
Priority: Critical
Hi,
A bit of context:
We are early adopters of Hibernate Search and we have very few problems with it (except
the @IndexEmbedded problem we helped to fix in 3.4.1, no problem so far).
When the DSL API was introduced, I tried it and I found the problem I describe below. I
decided to use the QueryParser API (and the MultiFieldQueryParser API) as a workaround.
The fact is that:
* we use Hibernate Search in every application we have, now;
* the DSL API is really nice and, as we introduced QueryDSL in our application, we now
use a lot of DSL like API and I would like to be able to use Hibernate Search API too;
* I thought it was a deliberate choice but, recently I found an example so weird, I
can't think it's the wanted behaviour.
So this problem isn't new and it exists since the first version of the DSL API.
Now, the description of the problem:
* we use the following analyzer to index a field in our entity:
{code}
@AnalyzerDef(name = HibernateSearchAnalyzer.TEXT,
tokenizer = @TokenizerDef(factory = WhitespaceTokenizerFactory.class),
filters = {
@TokenFilterDef(factory = ASCIIFoldingFilterFactory.class),
@TokenFilterDef(factory = WordDelimiterFilterFactory.class, params = {
@org.hibernate.search.annotations.Parameter(name =
"generateWordParts", value = "1"),
@org.hibernate.search.annotations.Parameter(name =
"generateNumberParts", value = "1"),
@org.hibernate.search.annotations.Parameter(name = "catenateWords",
value = "0"),
@org.hibernate.search.annotations.Parameter(name = "catenateNumbers",
value = "0"),
@org.hibernate.search.annotations.Parameter(name = "catenateAll",
value = "0"),
@org.hibernate.search.annotations.Parameter(name =
"splitOnCaseChange", value = "0"),
@org.hibernate.search.annotations.Parameter(name = "splitOnNumerics",
value = "0"),
@org.hibernate.search.annotations.Parameter(name = "preserveOriginal",
value = "1")
}
),
@TokenFilterDef(factory = LowerCaseFilterFactory.class)
}
),
{code}
* the content of the field is something like XXXX-AAAA-HAGYU-19910
* if you search for an exact match "XXXX-AAAA-HAGYU-19910" with the
QueryParser, you have a few results: namely the results which have all the different parts
(XXXX, AAAA, HAGYU and 19910) in any order. That's the behaviour I expect considering
my analyzer.
* if you search using the DSL API, you have ALL the results containing at least ONE token
so A LOT of results in our case.
My expectation is that the DSL API should work as the Lucene parser works and it should
return the same results.
The problem is that in ConnectedMultiFieldsTermQueryBuilder, we don't use the
QueryParser to build the Lucene query but a getAllTermsFromText() method which uses the
analyzer to get all the terms and from that we build a OR query.
So when I search for XXXX-AAAA-HAGYU-19910, the DSL API searches for "XXXX" OR
"AAAA" OR "HAGYU" OR "19910".
I really think it's a mistake and that we should use the *QueryParser API to build
the Lucene Query and have the correct behaviour.
If needed, I can provide any further information and/or a test case. I just want to be
sure you consider it a bug before working further on this. Otherwise I'll stick to
using the *QueryParser API.
Thanks for your feedback.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
4555
days inactive
4769
days old
hibernate-issues@lists.jboss.org
15 comments
4 participants
participants (4)
-
Emmanuel Bernard (JIRA) -
Guillaume Smet (JIRA)
-
Piotr Jagielski (JIRA)
-
Sanne Grinovero (JIRA)