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
Reporter: Jason Eacott
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