[
http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-572?pag...
]
Jason Eacott commented on HSEARCH-572:
--------------------------------------
Thanks Sanne,
I dont yet have a working NumericFields Bridge, and the more I look at it, the more work
it looks like.
I am currently using a simple Map Bridge like this:
public void set(String name,
Object value,
Document document,
LuceneOptions luceneOptions
){
final Map<String, Object> map = (Map<String, Object>) value;
for (final Map.Entry<String, Object> entry : map.entrySet()) {
if (entry.getValue() == null){
continue;
}
final String propertyName =name+"."+ entry.getKey();
final String propertyValue = entry.getValue().toString();
final Field field = new Field(propertyName, propertyValue, luceneOptions.getStore(),
luceneOptions.getIndex());
if (luceneOptions.getBoost() != null){
field.setBoost(luceneOptions.getBoost());
}
document.add(field);
}
}
where the content and type of each map element is not known at compile time.
its clear this works fine for Strings but when you need to include new lucene field types
then access to getStore() etc is required.
In fact, what I need here is probably something like the SOLR dynamicField config &
api.
eg some definition:
<dynamicField name="*_i" type="integer"
indexed="true" stored="true"/>
<dynamicField name="*_f" type="float"
indexed="true" stored="true"/>
<dynamicField name="*_tri" type="tint"
indexed="true" stored="true"/>
<dynamicField name="*_trf" type="tfloat"
indexed="true" stored="true"/>
...
and suitable code to determine the correct field type for a given fieldName, create the
fields, and add to document, and a queryBuilder implementation that can build suitable
queries.
solr already does this but from my brief peruse, its a fair chunk of code, and seems
tightly bound with solr. It still might be a good place to start.
a plea to reconsider deprecating luceneOptions.getStore(),
luceneOptions.getIndex() etc
---------------------------------------------------------------------------------------
Key: HSEARCH-572
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-572
Project: Hibernate Search
Issue Type: Deprecation
Components: mapping
Reporter: Jason Eacott
Assignee: Emmanuel Bernard
Fix For: 3.3.0
Maybe I'm missing something, but for a fieldBridge I've noticed that it is now
recommended to use luceneOptions.addFieldToDocument in place of document.add(new Field...
This decision seems a bit overzealous and optimistic to me, especially given the current
and significant lag in lucene version vs supported HibernateSearch version.
for example - if luceneOptions.getStore(), luceneOptions.getIndex() etc are not
deprecated then I can easily use them to create a custom field bridge for field types
unknown to hibernateSearch. While these methods remain it is very easy to create a dynamic
MapBridge for example that can choose to index a Map's key value pairs as Text or
NumericFields as appropriate (Since HSearch currently has no support for NumericFields
this is very useful). Without these methods, the options are much more limited.
So I'd just like to ask that either these methods remain, or an alternate arrangement
be made available whereby any lucene field type can be added to a document with suitable
index, store, boost, termvector etc.
Cheers.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira