Mailing-List: contact solr-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: solr-dev@lucene.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1077)
Subject: Re: SOLR-1131: disconnect between fields created by poly fields
From: Grant Ingersoll <gsingers@apache.org>
In-Reply-To: <87c998320912112108x4317db1as46807068a0610d5e@mail.gmail.com>
Date: Sun, 13 Dec 2009 06:35:31 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <6204E9BC-18C7-435D-B3EC-3BB740ACC204@apache.org>
References: <896ED647-AE0C-447F-B1DF-F0645D79D304@apache.org>
 <C7479CF9.78B5%Chris.A.Mattmann@jpl.nasa.gov>
 <c68e39170912110701x25d6ed2ao6f5a382a5cfd7862@mail.gmail.com>
 <87c998320912112108x4317db1as46807068a0610d5e@mail.gmail.com>
To: solr-dev@lucene.apache.org


On Dec 12, 2009, at 12:08 AM, Lance Norskog wrote:

> There are already components (ExtractingRequestHandler, Deduplication)
> that secretly add fields which violate the schema. Personally I would
> nuke this ability; I've had major problems with junk in the indexed
> data and discovering secret fields would have made my head explode
> that much louder.

Just as with any dynamic field, the Luke and the LukeRequestHandler are =
your friends.  Which reminds me, I need to mod the patch to have Luke =
spit out that it is a poly field.

I think the thing that is tricky here, is we are actually introducing a =
new layer of processing on top of Lucene that allows for more complex =
modeling by doing away with the notion that there is a 1-1 relationship =
between a FieldType and a Field.  Some people want explicit control, =
while others won't care about the details.


>=20
> On Fri, Dec 11, 2009 at 7:01 AM, Yonik Seeley
> <yonik@lucidimagination.com> wrote:
>> On Fri, Dec 11, 2009 at 9:53 AM, Mattmann, Chris A (388J)
>> <chris.a.mattmann@jpl.nasa.gov> wrote:
>>> Actually if it was the case that poly field mapped to a single =
dynamic
>>> field, then I would agree with you, but as is the discussion, poly =
field can
>>> map to _many_ dynamic fields, which is where the drift occurs.
>>=20
>> I'm not sure if we're using the exact same terminology, but it's well
>> defined how many dynamic fields would be created by the basic point
>> class (exactly one) *if* we decide to go that route and use that
>> option.  Can you give an examples of what you mean?  Is your =
objection
>> to this point class registering a single dynamic field, or are you
>> talking about a hypothetical case?
>>=20
>> -Yonik
>> http://www.lucidimagination.com
>>=20
>=20
>=20
>=20
> --=20
> Lance Norskog
> goksron@gmail.com