[hibernate-dev] API changes in FieldBridge

[Hardy Ferentschik]

Hi,

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)  
could
implement the method(s) in this interface to provide additional metadata  
like
the added field names.
This way we don't have to break existing bridge implementations.

--Hardy

On Wed, 07 Sep 2011 12:08:26 +0200, Sanne Grinovero <sanne at hibernate.org>  
wrote:

> 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
> Lucene-Fields.
>  - 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
> @AnalyzerDiscriminator
>
> For this one we have:
> HSEARCH-764 ClassBridge, DynamicBoost and AnalyzerDiscriminator should
> report affecting properties
>
> === Proposals ?
> Define on the interface as well:
> a)
> 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  
> allowSkipOnUnchangedFields()"
>  - 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.
>
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev