Mailing-List: contact solr-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: solr-user@lucene.apache.org
Received-SPF: pass (nike.apache.org: domain of
 SRS0=k2AYpo=PY=basetechnology.com=jack@yourhostingaccount.com designates
 65.254.253.52 as permitted sender)
Message-ID: <9F8EE2762B87410AB9E0A21CE47CC223@JackKrupansky>
From: "Jack Krupansky" <jack@basetechnology.com>
To: <solr-user@lucene.apache.org>
References: <mcgnnrnpsb08ixr9d6nfjgqf.1370674460481@email.android.com>
In-Reply-To: <mcgnnrnpsb08ixr9d6nfjgqf.1370674460481@email.android.com>
Subject: Re: custom field tutorial
Date: Sat, 8 Jun 2013 06:29:17 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="utf-8";
	reply-type=original
Content-Transfer-Encoding: 7bit
Importance: Normal
Sender: "Jack Krupansky" <jack@basetechnology.com>

Usually, people want to do the opposite - store the numeric code as a 
numeric field for perceived efficiency and let the user query and view 
results with the text form. But, there isn't any evidence of any great 
performance benefit of doing so - just store the string code in a string 
field.

Also, your language is confusing - you say "a single integer field that maps 
to the string field" - do you actually want two separate fields? Is that the 
case? If so, just let the user query against either field depending on what 
their preference is for numeric or string codes.

And your language seems to indicate that you want the user to query by 
numeric code but the field would be indexed as a string code. Is that the 
case?

Maybe you could clarify your intentions.

Sure, with custom code, custom fields, custom codecs, custom query parsers, 
etc. you can do almost anything - but... the initial challenge for any Solr 
app developer is to first try and see if they can make due with the existing 
capabilities.

-- Jack Krupansky

-----Original Message----- 
From: Anria Billavara
Sent: Saturday, June 08, 2013 2:54 AM
To: solr-user@lucene.apache.org
Subject: Re: custom field tutorial


You seem to know what you want the words to map to, so index the map.  Have 
one field for the word, one field for the mapped value, and at query time, 
search the words and return the mapped field. If it is comma separated, so 
be it and split it up in your code post search.
Otherwise, same as Wunder, in my many years in search this is an odd request
Anria

Sent from my Samsung smartphone on AT&T

-------- Original message --------
Subject: Re: custom field tutorial
From: Walter Underwood <wunder@wunderwood.org>
To: solr-user@lucene.apache.org
CC:

What are you trying to do? This seems really odd. I've been working in 
search for fifteen years and I've never heard this request.

You could always return all the fields to the client and ignore the ones you 
don't want.

wunder

On Jun 7, 2013, at 8:24 PM, geeky2 wrote:

> can someone point me to a "custom field" tutorial.
>
> i checked the wiki and this list - but still a little hazy on how i would 
> do
> this.
>
> essentially - when the user issues a query, i want my class to interrogate 
> a
> string field (containing several codes - example boo, baz, bar)
>
> and return a single integer field that maps to the string field 
> (containing
> the code).
>
> example:
>
> boo=1
> baz=2
> bar=3
>
> thx
> mark
>