Hardy Ferentschik
Wed, 23 Apr 2008 06:44:01 -0700
Wau - this feature greated more interest as expected ;-)On Wed, 23 Apr 2008 13:14:26 +0200, Sanne Grinovero <[EMAIL PROTECTED]> wrote:
IMHO I think it would be preferable to handle this in the DocumentBuilder,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.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.
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 viatheir 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 _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev