[hibernate-dev] Re: [Hibernate-JIRA] Commented: (HSEARCH-115) Add a default value for indexing null value

[Sanne Grinovero]

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 FieldBridge that adds this functionality, but
the special null marker Field is actually a constant and could be
added to the metaproperties at DocumentBuilder initialization; also
when building the Document you could test first for null
and avoid passing all other options to the FieldBridge, just adding
the constant Field to the document and skipping all further processing
for the current property.

We could skip this same processing also for properties which don't use
the new feature, effectively speeding it up a bit, so we don't feel
guilty for complicating the DocumentBuilder but are actually doing
some optimization and code cleanup.
Don't know if that is a dangerous optimization for backwards
compatibility... I expect no FieldBridge to generate Fields on a null
value but someone could rely on it..?

Also I'm not sure about adding @IndexNullMarker or adding an option to @Field,
what do others think about this?

Emmanuel said:
>If we go that path, we should add a NullQuery class that can be
combined with other >*Query from Lucene and hide the complexity.

This looks brilliant, but how should we instantiate a new NullQuery?
If an @IndexNullMarker option could override the used fieldname we
need a factory class with a reference to the DocumentBuilder or some
other way to discover the special field name,
so the simpleas way is to not have an option to choose the
keyword-fieldname and define it only from the property name. Would it
be acceptable that the user can't override the fieldname?

regards,
Sanne

2008/4/23, Hardy Ferentschik <hibernate at ferentschik.de>:
> Hi again :)
>
>  One more thing comes to my mind:
>
>  On Tue, 22 Apr 2008 18:47:14 +0200, Sanne Grinovero
> <sanne.grinovero at gmail.com> 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 handle the null marker. DocumentBuilder just iterates
> over the members
>  of the entity and for each with @Field annotated member calls the
> reponsible FieldBridge.
>  It also passes along additonal annotation values like the boost. It would
> make sense to handle the
>  @IndexNullMarker the same way, right?
>
>  --Hardy
>