To come back to Robert: We can of course remove the whole FieldTypes stuff altogether and only do this in Analyzer (which is then somehow a schema replacement). But then Analyzer.tokenStream() should be able to take other data types than Reader. If this would be the case I would +1 all your suggestions, izt would also solve the stupid wrapping of Strings with StringReader (that would be needed with removal of StringField)
Well its sorta always been this way, we tell people to check and make sure they use same analysis at index and query time. But with the current situation if they use things like StringFields and QueryParser they follow our best practices and get bogus or no results, thats why I get frustrated (this NOT_ANALYZED confusion has come up on the ML many times)
By the way as far as taking other data types than reader, i have no idea, i certainly feel like if we want to take String we could just apply StringReader ourself by default (someone could override). The problem with taking something other than reader would be the existence of charfilters in the chain (as these work on only readers).
dont care about QueryParser, because when you indexed a numeric field, you should create a Query on your own and not use this query parser, that corrumpts everything because of its syntax and whitespace handling.
But you added support for this to the flexible QP last summer as part of GSOC right (
LUCENE-1768) ? so its possible with Lucene's syntax? I'm confused I guess.