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@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
