Start here: http://wiki.apache.org/solr/HowToContribute
Then, when your patch is ready submit a JIRA and attach your patch. Then nudge (gently) if none of the committers picks it up and applies it.... NOTE: It is _not_ necessary that the first version of your patch is completely polished. I often put up partial/incomplete patches (comments with //nocommit are explicitly caught by the "ant precommit" target for instance) to see if anyone has any comments before polishing..... Best Erick On Thu, Jul 25, 2013 at 5:04 AM, Elran Dvir <elr...@checkpoint.com> wrote: > Hi, > > I have implemented like Chris described it: > The field is indexed as numeric, but displayed as string, according to > configuration. > It applies to facet, pivot, group and query. > > How do we proceed? How do I contribute it? > > Thanks. > > -----Original Message----- > From: Chris Hostetter [mailto:hossman_luc...@fucit.org] > Sent: Thursday, July 25, 2013 4:40 AM > To: solr-user@lucene.apache.org > Subject: Re: new field type - enum field > > > : Doable at Lucene level by any chance? > > Given how well the Trie fields compress (ByteField and ShortField have been > deprecated in favor of TrieIntField for this reason) it probably just makes > sense to treat it as a numeric at the Lucene level. > > : > If there's positive feedback, I'll open an issue with a patch for the > functionality. > > I've typically dealt with this sort of thing at the client layer using a > simple numeric field in Solr, or used an UpdateProcessor to convert the > String->numeric mapping when indexing & used clinet logic of a > DocTransformer to handle the stored value at query time -- but having a built > in FieldType that handles that for you automatically (and helps ensure the > indexed values conform to the enum) would certainly be cool if you'd like to > contribute it. > > > -Hoss > > Email secured by Check Point
