On Tue, 22 Apr 2008 18:47:14 +0200, Sanne Grinovero
[EMAIL PROTECTED] wrote:
Yes right but I don't see how this is worse than searching for
foo:bar OR foo:NULL-KEYWORD, just some less ambiguity.
If you just want to search for null fields, fooIsNull:true
It is not much worse, but as less
Hi again :)
One more thing comes to my mind:
On Tue, 22 Apr 2008 18:47:14 +0200, Sanne Grinovero
[EMAIL PROTECTED] wrote:
The Field and StringBridge API would remain as-is;
I am not so sure about that. Looking at the DocumentBuilder code it would
make sense to
let the FieldBridge
Hi,
hoping the rest of list users won't hate me:
IMHO I think it would be preferable to handle this in the DocumentBuilder,
so that people won't have to repeat this complexity in custom
FieldBridge implementations,
and you don't have to update all built-in FieldBridges.
We could make a wrapping
On Tue, 22 Apr 2008 03:29:18 +0200, Sanne Grinovero
[EMAIL PROTECTED] wrote:
A new proposal:
I got inspired by the 3VL considerations described in Emmanuel's
link to wikipedia, and think backwards compatibility is nice:
add a @IndexNullMarker on the property, this will add an additional
Field
Hey
The more I think about the feature, the less I like it.
Here is what I have written in Hibernate Search in Action
Hibernate Search, by default, does not store null attributes into the
index. Lucene does not have the notion of null fields, the field is
simply not there. Hibernate Search
