Wau - this feature greated more interest as expected ;-)
On Wed, 23 Apr 2008 13:14:26 +0200, Sanne Grinovero
<sanne.grinovero(a)gmail.com> wrote:
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.
Can definitely be done this way. The question is really
if it is a good
idea
design wise. So far the DocumentBuilder did not 'inspect' the actual
values.
Now we would have to test at the very least against null.
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..?
You never know. Some people might have
already implented null indexing via
their custom bridge or rely on for other reason on the fact that null
values
are passed to the FieldBridge. However, I agree that the DocumentBuilder
could
be cleaned up a little ;-)
--Hardy