[hibernate-dev] API changes in FieldBridge

[Emmanuel Bernard]

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