[ 
https://issues.apache.org/jira/browse/LUCENE-5870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14086463#comment-14086463
 ] 

Robert Muir commented on LUCENE-5870:
-------------------------------------

I am a little concerned about this, since it results in loss of information.

its similar to the parallel of removing TOKENIZED bit from stored fields before 
but yet still keeping StringField. This caused a lot of confusion for users.

Today, the Analyzer doesn't know have "full picture" because of 
StringField/IntField/FloatField and company "bypassing it". This causes a lot 
of pain, for example, you cannot even do a simple numeric range query with 
lucene without subclassing things with your "own additional schema".

In my opinion this stuff makes lucene too hard to use, because its too hard to 
reconstruct the doc from stored fields to e.g. perform an update to it and pass 
it back to indexwriter. Instead it tries to force people to either 
write/maintain a separate schema and subclass many things or force them to use 
some server that does this, which should not be necessary.

An alternative would be, if we removed StringField/IntField/LongField etc and 
these were instead just KeywordAnalyzer/IntAnalyzer whatever in the analysis 
chain, then queryparser could form range queries without subclassing, queries 
on string fields would just work, and the "schema" needed to search would be 
implicit all in one place (the users Analyzer), making lucene a lot easier to 
use.


> Simplify StoredFieldsVisitor
> ----------------------------
>
>                 Key: LUCENE-5870
>                 URL: https://issues.apache.org/jira/browse/LUCENE-5870
>             Project: Lucene - Core
>          Issue Type: Improvement
>            Reporter: Adrien Grand
>            Assignee: Adrien Grand
>             Fix For: 5.0, 4.10
>
>         Attachments: LUCENE-5870.patch
>
>
> StoredFieldVisitor has a visitor method for 4 numeric types: int, long, float 
> and double. We should remove this specialization and just have a method that 
> takes a java.lang.Number.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to