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 <[EMAIL PROTECTED]>: > 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 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 > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev