[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-904?pag... ] Hardy Ferentschik edited comment on HSEARCH-904 at 9/9/11 10:07 AM: -------------------------------------------------------------------- The last discussed solution was to create a new interface a bridge can optionally implement (similar to _ParameterizedBridge_) - _FieldNameReportingBridge_: {code} public interface FieldNameReportingBridge { Iterable<String> getGeneratedFieldNames(); } {code} Maybe we should introduce a wrapper object though to be able to not only return the names, but also analyzer names (see HSEARCH-664). To properly support this though the bridge implementation needs to know the property name to which the bridge applies. For this reason it makes sense to make bridges stateful and add an _initalize_ method which takes the field name (property name in most cases) and the _LuceneOptions_. These two parameters could then be removed from the _set_ method of _FieldBridge_ simplifying the API. The drawback of making the bridges stateful is a increased memory footprint (see above email thread) was (Author: hardy.ferentschik): The last discussed solution was to create a new interface a bridge can optionally implement (similar to _ParameterizedBridge_) - _FieldNameReportingBridge_: {code} public interface FieldNameReportingBridge { Iterable<String> getGeneratedFieldNames(); } {code} Maybe we should introduce a wrapper object though to be able to not only return the names, but also analyzer names (see HSEARCH-664). To properly support this though the bridge implementation needs to know the property name to which the bridge applies. For this reason it makes sense to make bridges stateful and add an _initalize_ method which takes the field name (property name in most cases) and the _LuceneOptions_. These two parameters could then be removed from the _set_ method of _FieldBridge_ simplifying the API. The drawback of making the bridges stateful is a increased memory footprint. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-904?pag... ] Hardy Ferentschik reassigned HSEARCH-904: ----------------------------------------- Assignee: Hardy Ferentschik -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-904?pag... ] Sanne Grinovero commented on HSEARCH-904: ----------------------------------------- bq. The more I think about, the less I like the idea of a wrapper. There are already other ways to handle the HSEARCH-664 usecase and it feels that the bridge should not know about analyzers. right, a bridge should not be coupled to an analyzer choice. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-904?pag... ] Hardy Ferentschik commented on HSEARCH-904: ------------------------------------------- Another idea which is inspired by _ConstraintValidator_ from Hibernate Validator. We could introduce a _IndexContext_ and pass it via set: {code} void set(Object value, Document document, IndexContext context) {code} The context could for example include the property hosting entity. If the entity is available from within the bridge implementation, the dynamic boosting functionality could be pushed into _LuceneOptions_. Having access to the entity might also be useful for other custom field bridges. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-904?pag... ] Hardy Ferentschik updated HSEARCH-904: -------------------------------------- Fix Version/s: (was: 4.0.0.Beta2) 4.1 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira