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