[hibernate-dev] API changes in FieldBridge

[Sanne Grinovero]

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