Mailing-List: contact java-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-user@lucene.apache.org
Received-SPF: pass (athena.apache.org: domain of jsaardchit@go2.com designates
 38.97.64.35 as permitted sender)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1082)
Subject: Re: Get Analyzed/Tokenized Field List
From: Jordon Saardchit <jsaardchit@go2.com>
In-Reply-To: <AANLkTim+4bSQ8WFhSR5sJ1MAH2Nmqd8hVfwNQFTVZzPm@mail.gmail.com>
Date: Thu, 23 Dec 2010 15:32:38 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <EFB94529-E150-4155-938C-4AE8432895C4@go2.com>
References: <E65782AA-EA1D-453C-8F1C-1C743B72E35E@go2.com>
 <AANLkTimpMwE-mp3fFspLUa4gR_-QbT_b0NkGLE5QqXLi@mail.gmail.com>
 <1A297333-56F0-4485-BD74-8E3DC96AE39E@go2.com>
 <AANLkTim+4bSQ8WFhSR5sJ1MAH2Nmqd8hVfwNQFTVZzPm@mail.gmail.com>
To: java-user@lucene.apache.org

The basic use case is determiniation of rules in regards to building a =
query.  I've got an application that programmatically builds queries =
(without any pre existing knowledge of the contents of the index it is =
searching).  We have a custom designed analyzer and filter chain.  =
However, it is applied to certain fields at index time.  The fields it =
is applied to are unstored.

On the search side, I want to be able to determine at runtime which =
field the analyzer should be applied to, and which field not to.  I =
could be approaching the solution incorrectly, but I figured this would =
be a pretty common or natural use case.

Jordon

On Dec 23, 2010, at 2:51 PM, Erick Erickson wrote:

> Ah, you didn't mention indexed but unstored in your original message,
> just indexed/analyzed....
>=20
> I don't think you can (someone jump in here if I'm wrong, please). The
> problem
> is that Lucene doesn't require any sort of schema. So if you are =
perfectly
> free to
> store a field in one document and NOT store it in another. All the =
variants
> specified in IndexReader.fieldOption can quickly be determined by just
> looking at the
> various index files. But you'd have to spin through all the =
#documents# in
> order
> to answer the question "is this field ever stored?". Sounds like a =
table
> scan in the
> DB world.
>=20
> I don't think Lucene keeps meta-data for this, and spinning through =
all the
> documents
> would be expensive...
>=20
> Why do you want to know? Perhaps there's another way to satisfy the
> use-case.
>=20
> I could be way off base here, I'm speaking from general principles not
> knowledge of
> the code...
>=20
> Best
> Erick
>=20
> On Thu, Dec 23, 2010 at 4:43 PM, Jordon Saardchit =
<jsaardchit@go2.com>wrote:
>=20
>> Yes I have, and after testing each of the various options denoted in
>> IndexReader.FieldOption, I cannot retrieve fieldnames that are =
indexed
>> (analyzed), and unstored.  I figured this would be relatively easy to =
do and
>> I was simply overlooking something.  Is it perhaps not possible to do =
this?
>>=20
>> Jordon
>>=20
>> On Dec 23, 2010, at 1:30 PM, Erick Erickson wrote:
>>=20
>>> Have you looked at IndexReader.getFieldNames()?
>>>=20
>>> Best
>>> Erick
>>>=20
>>> On Thu, Dec 23, 2010 at 3:23 PM, Jordon Saardchit =
<jsaardchit@go2.com
>>> wrote:
>>>=20
>>>> Is there an easy way to retrieve a collection of fields (or field =
names)
>>>> that are analyzed/tokenized from any given index?
>>>>=20
>>>> Jordon
>>>> =
---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail: java-user-help@lucene.apache.org
>>>>=20
>>>>=20
>>=20
>>=20
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-user-help@lucene.apache.org
>>=20
>>=20


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