On 7 sept. 2011, at 12:56, Sanne Grinovero wrote: > Hi Hardy, > if we decide that we don't have to break existing implementations, I'd > translate that into "move it out of 4.0". > > What about this mid-in solution: > > # we simplify the FieldBridge interface *even more* by disallowing it > to write directly to Document, but have it return a single String, > effectively forcing implementors to write to a single field which we > know about, and for which we can extrapolate all kind of > optimisations. This has the nice side-effect as the implementation > would be greatly simplified and not have to deal with LuceneOptions > and Document interfaces. > > We could have it return a Fieldable or a String; for the Fieldable I'd > check the field name is the expected one.
We already have a simple interface for common use cases, it's StringBridge / TwoWayStringBridge. FieldBridge is for complex use cases by essence. I might miss something but it looks like you are inventing something that already exists. > > # we create the new interface as you say which is going to be the more > powerful one, but an alternative rather than an extension, supporting > the full Document customization: adding multiple fields, overriding > indexing options. > Then we mandate on implementors of this one only to list the field > names being potentially used for a Document->Object conversion. Note that this is not always possible. Sometimes the field name depends on the data being indexed (think map key being part of the name). > > This would solve problem #1 having people effectively write less code. > The second type of bridges would also be less frequently used, which > could lead us into having to disable this kind of optimisations in > future (for currently unforeseen cases) less frequently. > > Sanne > > > On 7 September 2011 12:23, Hardy Ferentschik <ha...@hibernate.org> wrote: >> 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 >> > > _______________________________________________ > 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
