Deprecate and remove pint, plong & friends?

[Jan Høydahl <ja...@cominvent.com>]

Hi,

The only reason for the p* field types is backward compat with older configs.
But from 3.5 the Trie fields can fully replace p* fields.

I suggest that for 3.6 we deprecate solr.IntField w/friends in Java and add a deprecation warning to example schemas.
For 4.x we can remove them completely both from code and schema. Less is more...

Does this sound reasonable? If so, I can make a JIRA and a patch.

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com
Solr Training - www.solrtraining.com


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

Re: Deprecate and remove pint, plong & friends?

[Chris Hostetter <ho...@fucit.org>]

: : I suggest that for 3.6 we deprecate solr.IntField w/friends in Java and add a deprecation warning to example schemas.
: : For 4.x we can remove them completely both from code and schema. Less is more...

: -0 to removing the classes completley

I guess i should have said...

-0 to removing the classes completley

+1 to deprecating/removing the *name* IntField, etc.. and renaming these 
classes to something longer and less attractive looking to novice users 
(ie: StringifiedIntField) in 4.0

Unfortunately, as much as i would like to for "new users", i don't think 
it would be safe to renamed the TrieIntField (and freinds) to "IntField" 
in 4.0 given the havock it might wreck on any existing users of IntField.


-Hoss

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

Re: Deprecate and remove pint, plong & friends?

[Chris Hostetter <ho...@fucit.org>]

: The only reason for the p* field types is backward compat with older configs.
: But from 3.5 the Trie fields can fully replace p* fields.
: 
: I suggest that for 3.6 we deprecate solr.IntField w/friends in Java and add a deprecation warning to example schemas.
: For 4.x we can remove them completely both from code and schema. Less is more...

Aren't they still useful for people who built their indexes with lucene 
directly and (foolishly) indexed the number.toString()?  TrieField can't 
deal with that natively can it?

+1 to removing them from the examples (i thought we already had)
+1 to putting a big fat "you don't wnat this unless..." warning in 
   the javadocs
-0 to removing the classes completley

(when people say "i used this lucene code to build my index, can i search 
it with Solr?" it's nice to be able to say "yes, you can, but you should 
really consider reindexing" instead of "you have to reindex")

-Hoss

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