[hibernate-dev] API changes in FieldBridge

[Emmanuel Bernard]

#1
A specific interface is what looks the best to me too. 

#2 we might be able to reuse #1's interface. 
I don't fully understand what allowSkipOnUnchangedFields does.

On 7 sept. 2011, at 12:08, Sanne Grinovero 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