if we decide that we don't have to break existing implementations, I'd
translate that into "move it out of 4.0".
What about this mid-in solution:
# we simplify the FieldBridge interface *even more* by disallowing it
to write directly to Document, but have it return a single String,
effectively forcing implementors to write to a single field which we
know about, and for which we can extrapolate all kind of
optimisations. This has the nice side-effect as the implementation
would be greatly simplified and not have to deal with LuceneOptions
and Document interfaces.
We could have it return a Fieldable or a String; for the Fieldable I'd
check the field name is the expected one.
# we create the new interface as you say which is going to be the more
powerful one, but an alternative rather than an extension, supporting
the full Document customization: adding multiple fields, overriding
Then we mandate on implementors of this one only to list the field
names being potentially used for a Document->Object conversion.
This would solve problem #1 having people effectively write less code.
The second type of bridges would also be less frequently used, which
could lead us into having to disable this kind of optimisations in
future (for currently unforeseen cases) less frequently.
On 7 September 2011 12:23, Hardy Ferentschik <hardy(a)hibernate.org> wrote:
there is also HSEARCH-664 which is related to this discussion.
One alternative to modifying the bridge API is to add a new interface, eg
FieldBridgeMetaDataProvider. Custom bridges (and also our built-in ones)
implement the method(s) in this interface to provide additional metadata
the added field names.
This way we don't have to break existing bridge implementations.
On Wed, 07 Sep 2011 12:08:26 +0200, Sanne Grinovero <sanne(a)hibernate.org>
> We often had trouble applying strong optimisations because of the
> flexibility of the FieldBridge API, since 4.0 is coming it's time to
> decide if these limitations are going to stay, or if we have to change
> the contract.
> As far as I remember we can classify these limitations in two main areas:
> 1# when extracting stored values, we need to know which fields are needed
> (more details on HSEARCH-213), in short:
> - On entity-targeting queries we can't use a FieldSelector if the ID
> is using a unknown TwoWayFieldBridge, which might use multiple
> - On projection queries we can't use a FieldSelector if ANY field
> uses a TwoWayFieldBridge
> - Same scenarios, we can't use a FieldCache.
> For these cases we have
> HSEARCH-904 - Have TwoWayFieldBridge report which fields should be
> loaded from a Document
> === Proposals ?
> shall we add a "Iterable<String> getNeededFieldNames()" ?
> 2# when creating a o.a.l.Document, we want to know
> - which entity properties are going to affect the end result
> - if external input (current timestamp?) are going to affect it too
> this is important to make better use of dirty-ness information of the
> data, to see if we can skip the indexing operations at all, especially
> if re-indexing is going to reload a significant subgraph via
> @IndexedEmbedded and similar.
> N.B. this same optimisation should apply to @DynamicBoost and
> For this one we have:
> HSEARCH-764 ClassBridge, DynamicBoost and AnalyzerDiscriminator should
> report affecting properties
> === Proposals ?
> Define on the interface as well:
> boolean allowSkipOnUnchangedFields() // can return false to disable
> any optimisation, like to add the current date to the index or
> externally loaded data
> Iterable<String> getInputPropertyNames() //this is the hard point:
> very unsafe stuff.
> b)alternatively we could not pass the entity directly but interecept
> it and see which properties are being used in practice:
> - quite more powerful if the fieldBridge has some branching logic
> which leads it to use different fields according to other state
> - hard to intercept field accessors: would we limit it to getter
> using entities only?
> - would still need the global toggle "boolean
> - since it won't really change the API - besides the boolean switch -
> could be implemented later.
> Please comment, we had this ideas around for some time but the time as
> come to write down how it's going to work.
> hibernate-dev mailing list
hibernate-dev mailing list