[hibernate-dev] API changes in FieldBridge
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 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 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
Re: [hibernate-dev] API changes in FieldBridge
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 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 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 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
Re: [hibernate-dev] API changes in FieldBridge
#1 A specific interface is what looks the best to me too. #2 we might be able to reuse #1's interface. I don't fully understand what allowSkipOnUnchangedFields does. On 7 sept. 2011, at 12:08, Sanne Grinovero 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 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 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
Re: [hibernate-dev] API changes in FieldBridge
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 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. 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 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 > 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 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 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
Re: [hibernate-dev] API changes in FieldBridge
On 7 September 2011 12:43, Emmanuel Bernard wrote: > #1 > A specific interface is what looks the best to me too. > > #2 we might be able to reuse #1's interface. > I don't fully understand what allowSkipOnUnchangedFields does. I think we need a way for implementors to state that the index needs to be updated even if all the listed properties are not considered dirty, basically a toggle to disable the optimisation for a specific bridge implementation. Example: when the entity is updated, and no indexed fields are changed, but we still want to store a "last updated timestamp" in the Lucene index. If you think we don't need it I'll be glad to leave it out. Sanne ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] API changes in FieldBridge
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 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 >> 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 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 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 ti
Re: [hibernate-dev] API changes in FieldBridge
On 7 sept. 2011, at 13:01, Sanne Grinovero wrote: > On 7 September 2011 12:43, Emmanuel Bernard wrote: >> #1 >> A specific interface is what looks the best to me too. >> >> #2 we might be able to reuse #1's interface. >> I don't fully understand what allowSkipOnUnchangedFields does. > > I think we need a way for implementors to state that the index needs > to be updated even if all the listed properties are not considered > dirty, basically a toggle to disable the optimisation for a specific > bridge implementation. OK, got it. The absence of this TargetedFields (or whatever name we could give it) interface would be equivalent to allowSkipOnUnchangedField = false for a bridge. Likewise for DynamicBoost and DynamicAnalyzer. Of course an additional interface is less in your face than an explicit method on the existing interfaces. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] API changes in FieldBridge
On 7 September 2011 13:04, Emmanuel Bernard wrote: > > 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. Right that would fit perfectly, but the mapping annotations take a FieldBridge implementation (@Field, @FieldBridge) so while the most common case is likely applying a StringBridge via it's TwoWayString2FieldBridgeAdaptor, we're still dealing with a FieldBridge. This seems to suggest we should treat the optimisations differently by checking if the implementation is a TwoWayString2FieldBridgeAdaptor, and add what we eventually need to this internal class. >> # 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). Right, it should be possible to say "I can't know, please return them all" and have any field-loading optimisation strategy disabled. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] API changes in FieldBridge
On 7 September 2011 13:17, Sanne Grinovero wrote: > On 7 September 2011 13:04, Emmanuel Bernard wrote: >> >> 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. > > Right that would fit perfectly, but the mapping annotations take a > FieldBridge implementation (@Field, @FieldBridge) so while the most > common case is likely applying a StringBridge via it's > TwoWayString2FieldBridgeAdaptor, we're still dealing with a > FieldBridge. > This seems to suggest we should treat the optimisations differently by > checking if the implementation is a TwoWayString2FieldBridgeAdaptor, > and add what we eventually need to this internal class. sorry let me amend this. That won't be enough, as our goal is to make it possible for people to plug in custom implementations of TwoWayStringBridge. Should be good enough to allow passing to these annotations either a class implementing TwoWayFieldBridge or implementing TwoWayStringBridge ? The in case of a TwoWayFieldBridge we can additionally check if it happens to be a TwoWayString2FieldBridgeAdaptor. This all looks like to boil down to the fact that we don't need to change backwards compatible APIs, WDYT, should these optimisations be coded in a version > 4.0 ? ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] API changes in FieldBridge
> > OK, got it. > The absence of this TargetedFields (or whatever name we could give it) > interface would be equivalent to allowSkipOnUnchangedField = false for a > bridge. Likewise for DynamicBoost and DynamicAnalyzer. > Of course an additional interface is less in your face than an explicit > method on the existing interfaces. I'm fully aligned. That looks like the best approach, but I don't like it much to deal with complex hierarchies of interfaces - which need to be well understood by users - and behave differently according to the fact a method is defined or not. It would be nice if we could enable optimisations more transparently, but I see this looks like is the best we can do without going for the proxy path. Sanne ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] API changes in FieldBridge
On Wed, 07 Sep 2011 12:56:26 +0200, Sanne Grinovero wrote: > if we decide that we don't have to break existing implementations, I'd > translate that into "move it out of 4.0". It does not HAVE TO be moved out in this case. It will really depend if one of us has time to work on this. On the other hand, if not we can defer the change for 4.1 since it is backward compatible. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] API changes in FieldBridge
On 7 sept. 2011, at 13:17, Sanne Grinovero wrote:
>>
>> 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.
>
> Right that would fit perfectly, but the mapping annotations take a
> FieldBridge implementation (@Field, @FieldBridge) so while the most
> common case is likely applying a StringBridge via it's
> TwoWayString2FieldBridgeAdaptor, we're still dealing with a
> FieldBridge.
No, the mapping annotation accepts StringBridge / FieldBridge and their TwoWay
counterparts.
> This seems to suggest we should treat the optimisations differently by
> checking if the implementation is a TwoWayString2FieldBridgeAdaptor,
> and add what we eventually need to this internal class.
That made me realize. Most of our bridges are stateless wrt the field name. ie
the field name is passed as a parameter and we use it. Even many user provided
FieldBridge will be like that. Which means getTargetedFieldNames() is not
implementable for such bridges.
One alternative approach would be to use annotations on the FieldBridge
implementation
@TargetedFields(value=PROVIDED_FIELD_NAME)
@TargetedFields(value=FIELD_LIST, fieldList={"foo", "bar"})
@TargetedFields(value=ALL)
we can even later implement if that makes sense
@TargetedFields(value=FIELD_PREFIXES, fieldList="foo") //all fields starting
with foo
Most of our fields would use @TargetedFields(value=PROVIDED_FIELD_NAME)
The names are not good yet but you get the idea.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] API changes in FieldBridge
On Wed, 07 Sep 2011 13:27:17 +0200, Sanne Grinovero wrote: >> >> OK, got it. >> The absence of this TargetedFields (or whatever name we could give it) >> interface would be equivalent to allowSkipOnUnchangedField = false for >> a bridge. Likewise for DynamicBoost and DynamicAnalyzer. >> Of course an additional interface is less in your face than an explicit >> method on the existing interfaces. > > I'm fully aligned. That looks like the best approach, but I don't like > it much to deal with complex hierarchies of interfaces It is not really a hierarchy. It is just an additional interface a bridge can implement. Think of Scala traits. There almost everything is its own interface (for good and for bad) And yes, I am not a big fan of deep hierarchies either. --Hardy ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] API changes in FieldBridge
Summary: we won't use the annotations, but we will add additional
Interfaces in future, which will be optional.
The only change needed for 4.0 to make this possible later is to make
the FieldBridge implementations stateful: they will need an initialize
method
to receive the field name and LuceneOptions. These same parameters are
currently passed to the set(...) method and will be removed from
there.
Why, and future plan:
Edited IRC log, I actually tried to shorten it a bit, taking out the
fun parts..:)
FIELD_PREFIXES might make sense too :) a
FieldSelector can make good use of that.
RE "No, the mapping annotation accepts StringBridge /
FieldBridge and their TwoWay counterparts."
really didn't know that, I'm glad you had time to
inspect my rants. I still have something to learn from Search.
:)
I like the annotation approach too though I'm not fan of
the names yet
talking about bridges, was there not an issue once to sort out
some of the inheritance used in these classes
RE: "That made me realize. Most of our bridges are
stateless wrt the field name. ie the field name is passed as a
parameter and we use it."
if I remember correctly there was some sort of "problem/issue"
that leads me to think we should otherwise inject the
field name and options to the bridge, and have it statefull
hardy, you mean with the inheritance of interfaces of
the FieldBridge & co, or the annotated entities ?
of the FieldBridge
I am pretty sure that used to be a Jira or a todo somewhere
I don't remember. I might have brought up that we
have too many and that I get confused on them :)
/ FIXME rework the interface inheritance there are some common
concepts with StringBridge
in TwoWayFieldBridge
* emmanuel has quit (Ping timeout: 246 seconds)
right, that's the one I referred to, and why it
scared me a bit to add more variants to them.
sure
but as I said I was not talking about interface inhertiance
my suggestion was a new independet interface
maybe we should figure out what this comment actually means
and address the issue and/or remove the comment
yes got that during lunch :) I'm not super happy but
it's clearly the best proposal so far.
imo it is a good solution
yes well as I said it just scares me a bit, mostly
because as I just have proven on the mailing list I'm not very
familiar with this area and gets me confused. might well be that if I
happen to code this I'll love it after the deep-dive
hardy, did you find an issue for that FIXME you referred to?
I haven't looked
because an annotation can be added later, but
breaking the interfaces should be done asap if we in fact get a good
grasp on this
and to answer on your last mail: we really need to
push out of the schedule just everything which is not needed for 4.0,
there's way too much already.
so what I'm trying to do now is to clarify as much as
possible how exactly the API has to change, in such a way that we will
be able to add new cool features and additional optimisations in
future, we have so many ideas but they won't fit all.
sure
given our tight schedule i think it makes sense to not break
the interface
we seem to have a backward compatible solution for a 4.x version
of course if there is no need to break it we won't,
but if we later figure out we where needing it where' stuck again
so for now my plan was that
if we need to mandate a new method, we can as well
ignore it for 4.0 but we have to declare it in the interface
just that this is incredibly hard to do in practice :)
can we boil down a proposal to send to ML for when
emmanuel returns?
so what's the options?
#1 new interface a bridge can implement
#2 a new @TargetedFields annotation
is this what it boils down to?
yes but I'm not sure if they are alternatives, it
looks more like 1# solves problem one and 2# solved problem 2 :)
as how I had numbered them in the first email
got you
yes maybe it was wrong to push in so many issues in
the same thread, but they are all related
of course
on @TargetedFields, how do you see it relate the
actual field names to the name passed as a parameter? an annotation is
static ..
looks like the @TargetedFields options will need a
placeholder token for the fieldname they are used on
but this quite complicates the re-use of such an
instance on different properties, looks like we will need to make it a
stateful component.
I don't follow
example, assuming you have Search's src open:
open now
actually this will work better:
http://docs.jboss.org/hibernate/stable/search/reference/en-US/html_single/#example-field-bridge
you see the "set(String name ... other parameters)"
then the implementation forges the "[name].year",
"[name].month" fields
yes
so this implementation should be annotated as using
which fields?
when annotating it with @TargetedFields I won't know
the value of the name parameter
it should be something like
@TargetedFields(value=FIELD_LIST,
fieldList={"bornAt.year", ""bornAt.month"})
but the "bornAt" is not known when you
Re: [hibernate-dev] API changes in FieldBridge
I had to read the conversation quickly. A couple of comments. I am concerned about making FieldBridge a stateful component, this will increase our metadata footprint by a lot. Most bridges are currently singletons. This won't be possible with this new design approach. LucemeOptions is not so much a data placeholder than a holder for helper methods (namely addFieldToDocument, addNumericFieldToDocument) which use the proper user declared settings wrt Lucene options. Remember we almost got the getters removed from this interface at one point. On 7 sept. 2011, at 19:35, Sanne Grinovero wrote: > Summary: we won't use the annotations, but we will add additional > Interfaces in future, which will be optional. > The only change needed for 4.0 to make this possible later is to make > the FieldBridge implementations stateful: they will need an initialize > method > to receive the field name and LuceneOptions. These same parameters are > currently passed to the set(...) method and will be removed from > there. > > Why, and future plan: > Edited IRC log, I actually tried to shorten it a bit, taking out the > fun parts..:) > > FIELD_PREFIXES might make sense too :) a > FieldSelector can make good use of that. > RE "No, the mapping annotation accepts StringBridge / > FieldBridge and their TwoWay counterparts." > really didn't know that, I'm glad you had time to > inspect my rants. I still have something to learn from Search. > :) > I like the annotation approach too though I'm not fan of > the names yet > talking about bridges, was there not an issue once to sort out > some of the inheritance used in these classes > RE: "That made me realize. Most of our bridges are > stateless wrt the field name. ie the field name is passed as a > parameter and we use it." > if I remember correctly there was some sort of "problem/issue" > that leads me to think we should otherwise inject the > field name and options to the bridge, and have it statefull > hardy, you mean with the inheritance of interfaces of > the FieldBridge & co, or the annotated entities ? > of the FieldBridge > I am pretty sure that used to be a Jira or a todo somewhere > I don't remember. I might have brought up that we > have too many and that I get confused on them :) > / FIXME rework the interface inheritance there are some common > concepts with StringBridge > in TwoWayFieldBridge > * emmanuel has quit (Ping timeout: 246 seconds) > right, that's the one I referred to, and why it > scared me a bit to add more variants to them. > sure > but as I said I was not talking about interface inhertiance > my suggestion was a new independet interface > maybe we should figure out what this comment actually means > and address the issue and/or remove the comment > yes got that during lunch :) I'm not super happy but > it's clearly the best proposal so far. > imo it is a good solution > yes well as I said it just scares me a bit, mostly > because as I just have proven on the mailing list I'm not very > familiar with this area and gets me confused. might well be that if I > happen to code this I'll love it after the deep-dive > hardy, did you find an issue for that FIXME you referred to? > I haven't looked > because an annotation can be added later, but > breaking the interfaces should be done asap if we in fact get a good > grasp on this > and to answer on your last mail: we really need to > push out of the schedule just everything which is not needed for 4.0, > there's way too much already. > so what I'm trying to do now is to clarify as much as > possible how exactly the API has to change, in such a way that we will > be able to add new cool features and additional optimisations in > future, we have so many ideas but they won't fit all. > sure > given our tight schedule i think it makes sense to not break > the interface > we seem to have a backward compatible solution for a 4.x version > of course if there is no need to break it we won't, > but if we later figure out we where needing it where' stuck again > so for now my plan was that > if we need to mandate a new method, we can as well > ignore it for 4.0 but we have to declare it in the interface > just that this is incredibly hard to do in practice :) > can we boil down a proposal to send to ML for when > emmanuel returns? > so what's the options? > #1 new interface a bridge can implement > #2 a new @TargetedFields annotation > is this what it boils down to? > yes but I'm not sure if they are alternatives, it > looks more like 1# solves problem one and 2# solved problem 2 :) > as how I had numbered them in the first email > got you > yes maybe it was wrong to push in so many issues in > the same thread, but they are all related > of course > on @TargetedFields, how do you see it relate the > actual field names to the name passed as a parameter? an annotation is > static .. > looks like the @TargetedFields options will need a > placeholder token for the fieldna
Re: [hibernate-dev] API changes in FieldBridge
On 7 September 2011 20:07, Emmanuel Bernard wrote: > I had to read the conversation quickly. A couple of comments. > > I am concerned about making FieldBridge a stateful component, this will > increase our metadata footprint by a lot. Most bridges are currently > singletons. This won't be possible with this new design approach. > > LucemeOptions is not so much a data placeholder than a holder for helper > methods (namely addFieldToDocument, addNumericFieldToDocument) which use the > proper user declared settings wrt Lucene options. Remember we almost got the > getters removed from this interface at one point. we'll keep this in mind and polish the idea looking for ways to minimize the footprint: we can reuse instances where possible, for example all the wrapped StringBridge implementations don't need to be duplicated, and what we add to the FieldBridge will be removed from where it used to be. Also, this doesn't affect StringBridges which are more frequently used. Sanne ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] API changes in FieldBridge
On Wed, 07 Sep 2011 20:07:42 +0200, Emmanuel Bernard wrote: > I am concerned about making FieldBridge a stateful component, this will > increase our metadata footprint by a lot. Most bridges are currently > singletons. This won't be possible with this new design approach. do you really think this is an issue. See Sanne's comments and these are not heavy weight objects. --Hardy ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] NOTE: hibernate-core 3.6 is using JDK 1.5!
this has caused many times our hudson job fail due to using JDK 6 api or using @Override annotation on a method that does not actually override a superclass method (but an interface). --- Strong Liu http://hibernate.org http://github.com/stliu ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
