You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Erick Erickson <er...@gmail.com> on 2014/03/20 18:52:02 UTC
Analyzing primitive types, why can't we do this in Solr?
It's bugged me for a while that we can't define any analysis on
primitive types. This is especially acute with date types, we require
a very exact format and have to tell people "transform it correctly on
the ingestion side", or "create an custom update processor that
transforms it".
I thought I remembered something about being able to do this, but
can't find it. I suspect I was confusing it with DIH.
What's the reason for primitive types being unanalyzed? Just "it's
always been that way", or "it would lead to a very sticky wicket we
never wanted to get stuck in"? Both are perfectly valid, I'm just
sayin'.
I realize this would provide some "interesting" output. Say you
defined a regex for an int type that removed all non-numerics. If the
input was "30asdf" and it was transformed correctly into 30 for the
underlying int field, it would still come back as 30asdf from the
stored data, but that's true about all analysis steps.
Or perhaps you'd like to have a string of integers as input to a
multiValued int field. Or....
Musings sparked by seeing this crop up again in another context.
Erick
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Analyzing primitive types, why can't we do this in Solr?
Posted by Alexandre Rafalovitch <ar...@gmail.com>.
Hi Erick,
Maybe work with me offline on that idea. Sounds interesting and I
would love to hear more details. There is more Solr popularization
stuff in works as well, so plenty of opportunities for - ugh -
synergies.
Regards,
Alex.
Personal website: http://www.outerthoughts.com/
LinkedIn: http://www.linkedin.com/in/alexandrerafalovitch
- Time is the quality of nature that keeps events from happening all
at once. Lately, it doesn't seem to be working. (Anonymous - via GTD
book)
On Fri, Mar 21, 2014 at 8:20 AM, Erick Erickson <er...@gmail.com> wrote:
> Yeah, I finally got a little smart and clicked the hierarchy builder
> link in IntelliJ when resting on UpdateRequestProcessorFactory. I
> don't use the built-in IDE tools _nearly_ enough.
>
> That page looks great BTWl. I'm going to follow a parallel path with
> the Solr docs that I think will complement yours, just a brief outline
> of what's there similar to the "Analyzers and Tokenizers" page.... If
> I find the time... Siigggh.
>
> Erick
>
> On Thu, Mar 20, 2014 at 5:53 PM, Alexandre Rafalovitch
> <ar...@gmail.com> wrote:
>> That "chain" issue is exactly why I built the web page above. That,
>> plus the Javadoc links all over the place.
>>
>> Next, I am working on a similar page for all Solr Analyzers,
>> Tokenizers and Filters. Should be ready soon.
>>
>> Regards,
>> Alex.
>> Personal website: http://www.outerthoughts.com/
>> LinkedIn: http://www.linkedin.com/in/alexandrerafalovitch
>> - Time is the quality of nature that keeps events from happening all
>> at once. Lately, it doesn't seem to be working. (Anonymous - via GTD
>> book)
>>
>>
>> On Fri, Mar 21, 2014 at 7:50 AM, Erick Erickson <er...@gmail.com> wrote:
>>> Thanks Alexandre! That's what I _thought_ I remembered!
>>>
>>> It looks like I found all the extends for UpdateProcessorFactory, but
>>> didn't follow the chain through FieldMutatingUpdateProcessorFactory
>>> which would have found that one for me.
>>>
>>> Siiigggghhh.
>>>
>>> Thanks again,
>>> Erick
>>>
>>> On Thu, Mar 20, 2014 at 5:44 PM, Alexandre Rafalovitch
>>> <ar...@gmail.com> wrote:
>>>> Do you mean like:
>>>> http://lucene.apache.org/solr/4_6_1/solr-core/org/apache/solr/update/processor/ParseDateFieldUpdateProcessorFactory.html
>>>> ?
>>>> https://github.com/apache/lucene-solr/blob/lucene_solr_4_7_0/solr/example/example-schemaless/solr/collection1/conf/solrconfig.xml#L1570
>>>>
>>>> Regards,
>>>> Alex.
>>>> P.s. Quick URP lookup comes to you courtesy of:
>>>> http://www.solr-start.com/update-request-processor/4.6.1/ :-)
>>>>
>>>> On Fri, Mar 21, 2014 at 2:35 AM, Erick Erickson <er...@gmail.com> wrote:
>>>>> I suppose for the special case of dates we could create a
>>>>> DateFormatProcessorFactory that just took a list of standard Java
>>>>> SimpleDateFormat strings and applied the first one that fit.
>>>>
>>>>
>>>>
>>>> Personal website: http://www.outerthoughts.com/
>>>> LinkedIn: http://www.linkedin.com/in/alexandrerafalovitch
>>>> - Time is the quality of nature that keeps events from happening all
>>>> at once. Lately, it doesn't seem to be working. (Anonymous - via GTD
>>>> book)
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Analyzing primitive types, why can't we do this in Solr?
Posted by Erick Erickson <er...@gmail.com>.
Yeah, I finally got a little smart and clicked the hierarchy builder
link in IntelliJ when resting on UpdateRequestProcessorFactory. I
don't use the built-in IDE tools _nearly_ enough.
That page looks great BTWl. I'm going to follow a parallel path with
the Solr docs that I think will complement yours, just a brief outline
of what's there similar to the "Analyzers and Tokenizers" page.... If
I find the time... Siigggh.
Erick
On Thu, Mar 20, 2014 at 5:53 PM, Alexandre Rafalovitch
<ar...@gmail.com> wrote:
> That "chain" issue is exactly why I built the web page above. That,
> plus the Javadoc links all over the place.
>
> Next, I am working on a similar page for all Solr Analyzers,
> Tokenizers and Filters. Should be ready soon.
>
> Regards,
> Alex.
> Personal website: http://www.outerthoughts.com/
> LinkedIn: http://www.linkedin.com/in/alexandrerafalovitch
> - Time is the quality of nature that keeps events from happening all
> at once. Lately, it doesn't seem to be working. (Anonymous - via GTD
> book)
>
>
> On Fri, Mar 21, 2014 at 7:50 AM, Erick Erickson <er...@gmail.com> wrote:
>> Thanks Alexandre! That's what I _thought_ I remembered!
>>
>> It looks like I found all the extends for UpdateProcessorFactory, but
>> didn't follow the chain through FieldMutatingUpdateProcessorFactory
>> which would have found that one for me.
>>
>> Siiigggghhh.
>>
>> Thanks again,
>> Erick
>>
>> On Thu, Mar 20, 2014 at 5:44 PM, Alexandre Rafalovitch
>> <ar...@gmail.com> wrote:
>>> Do you mean like:
>>> http://lucene.apache.org/solr/4_6_1/solr-core/org/apache/solr/update/processor/ParseDateFieldUpdateProcessorFactory.html
>>> ?
>>> https://github.com/apache/lucene-solr/blob/lucene_solr_4_7_0/solr/example/example-schemaless/solr/collection1/conf/solrconfig.xml#L1570
>>>
>>> Regards,
>>> Alex.
>>> P.s. Quick URP lookup comes to you courtesy of:
>>> http://www.solr-start.com/update-request-processor/4.6.1/ :-)
>>>
>>> On Fri, Mar 21, 2014 at 2:35 AM, Erick Erickson <er...@gmail.com> wrote:
>>>> I suppose for the special case of dates we could create a
>>>> DateFormatProcessorFactory that just took a list of standard Java
>>>> SimpleDateFormat strings and applied the first one that fit.
>>>
>>>
>>>
>>> Personal website: http://www.outerthoughts.com/
>>> LinkedIn: http://www.linkedin.com/in/alexandrerafalovitch
>>> - Time is the quality of nature that keeps events from happening all
>>> at once. Lately, it doesn't seem to be working. (Anonymous - via GTD
>>> book)
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Analyzing primitive types, why can't we do this in Solr?
Posted by Alexandre Rafalovitch <ar...@gmail.com>.
That "chain" issue is exactly why I built the web page above. That,
plus the Javadoc links all over the place.
Next, I am working on a similar page for all Solr Analyzers,
Tokenizers and Filters. Should be ready soon.
Regards,
Alex.
Personal website: http://www.outerthoughts.com/
LinkedIn: http://www.linkedin.com/in/alexandrerafalovitch
- Time is the quality of nature that keeps events from happening all
at once. Lately, it doesn't seem to be working. (Anonymous - via GTD
book)
On Fri, Mar 21, 2014 at 7:50 AM, Erick Erickson <er...@gmail.com> wrote:
> Thanks Alexandre! That's what I _thought_ I remembered!
>
> It looks like I found all the extends for UpdateProcessorFactory, but
> didn't follow the chain through FieldMutatingUpdateProcessorFactory
> which would have found that one for me.
>
> Siiigggghhh.
>
> Thanks again,
> Erick
>
> On Thu, Mar 20, 2014 at 5:44 PM, Alexandre Rafalovitch
> <ar...@gmail.com> wrote:
>> Do you mean like:
>> http://lucene.apache.org/solr/4_6_1/solr-core/org/apache/solr/update/processor/ParseDateFieldUpdateProcessorFactory.html
>> ?
>> https://github.com/apache/lucene-solr/blob/lucene_solr_4_7_0/solr/example/example-schemaless/solr/collection1/conf/solrconfig.xml#L1570
>>
>> Regards,
>> Alex.
>> P.s. Quick URP lookup comes to you courtesy of:
>> http://www.solr-start.com/update-request-processor/4.6.1/ :-)
>>
>> On Fri, Mar 21, 2014 at 2:35 AM, Erick Erickson <er...@gmail.com> wrote:
>>> I suppose for the special case of dates we could create a
>>> DateFormatProcessorFactory that just took a list of standard Java
>>> SimpleDateFormat strings and applied the first one that fit.
>>
>>
>>
>> Personal website: http://www.outerthoughts.com/
>> LinkedIn: http://www.linkedin.com/in/alexandrerafalovitch
>> - Time is the quality of nature that keeps events from happening all
>> at once. Lately, it doesn't seem to be working. (Anonymous - via GTD
>> book)
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Analyzing primitive types, why can't we do this in Solr?
Posted by Erick Erickson <er...@gmail.com>.
Thanks Alexandre! That's what I _thought_ I remembered!
It looks like I found all the extends for UpdateProcessorFactory, but
didn't follow the chain through FieldMutatingUpdateProcessorFactory
which would have found that one for me.
Siiigggghhh.
Thanks again,
Erick
On Thu, Mar 20, 2014 at 5:44 PM, Alexandre Rafalovitch
<ar...@gmail.com> wrote:
> Do you mean like:
> http://lucene.apache.org/solr/4_6_1/solr-core/org/apache/solr/update/processor/ParseDateFieldUpdateProcessorFactory.html
> ?
> https://github.com/apache/lucene-solr/blob/lucene_solr_4_7_0/solr/example/example-schemaless/solr/collection1/conf/solrconfig.xml#L1570
>
> Regards,
> Alex.
> P.s. Quick URP lookup comes to you courtesy of:
> http://www.solr-start.com/update-request-processor/4.6.1/ :-)
>
> On Fri, Mar 21, 2014 at 2:35 AM, Erick Erickson <er...@gmail.com> wrote:
>> I suppose for the special case of dates we could create a
>> DateFormatProcessorFactory that just took a list of standard Java
>> SimpleDateFormat strings and applied the first one that fit.
>
>
>
> Personal website: http://www.outerthoughts.com/
> LinkedIn: http://www.linkedin.com/in/alexandrerafalovitch
> - Time is the quality of nature that keeps events from happening all
> at once. Lately, it doesn't seem to be working. (Anonymous - via GTD
> book)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Analyzing primitive types, why can't we do this in Solr?
Posted by Alexandre Rafalovitch <ar...@gmail.com>.
Do you mean like:
http://lucene.apache.org/solr/4_6_1/solr-core/org/apache/solr/update/processor/ParseDateFieldUpdateProcessorFactory.html
?
https://github.com/apache/lucene-solr/blob/lucene_solr_4_7_0/solr/example/example-schemaless/solr/collection1/conf/solrconfig.xml#L1570
Regards,
Alex.
P.s. Quick URP lookup comes to you courtesy of:
http://www.solr-start.com/update-request-processor/4.6.1/ :-)
On Fri, Mar 21, 2014 at 2:35 AM, Erick Erickson <er...@gmail.com> wrote:
> I suppose for the special case of dates we could create a
> DateFormatProcessorFactory that just took a list of standard Java
> SimpleDateFormat strings and applied the first one that fit.
Personal website: http://www.outerthoughts.com/
LinkedIn: http://www.linkedin.com/in/alexandrerafalovitch
- Time is the quality of nature that keeps events from happening all
at once. Lately, it doesn't seem to be working. (Anonymous - via GTD
book)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Analyzing primitive types, why can't we do this in Solr?
Posted by Erick Erickson <er...@gmail.com>.
And one of my co-workers reminded me of what can be used in Solr right
now to accomplish this, so the problem is moot.
RegexReplaceProcessorFactory
Gets inserted into Solr's update process before it gets fed to the
field, so any transformations one wants to do can be done there.
I guess the only thing I can't do would be to feed in multiple values
to the primitive type field, but that's no big deal....
I suppose for the special case of dates we could create a
DateFormatProcessorFactory that just took a list of standard Java
SimpleDateFormat strings and applied the first one that fit.
On Thu, Mar 20, 2014 at 11:57 AM, Erick Erickson
<er...@gmail.com> wrote:
> Uwe:
>
> Thanks! I peeked at the code briefly and I see that it would
> be hard.
>
> Figured there was a good reason.
>
> What about a higher-level approach? I'm thinking a thin
> wrapper for Solr that would apply the analysis chains and feed
> the results into the native Lucene primitive processing. Seems
> kind of kludgy, I'm mostly wondering if it's conceptually
> possible/reasonable.
>
> Frankly, I'm not convinced there's enough all for something like
> this to justify the work/complexification though.
>
> Erick
>
> On Thu, Mar 20, 2014 at 11:17 AM, Uwe Schindler <uw...@thetaphi.de> wrote:
>> Hi Erick,
>>
>> The numerics are in fact "analyzed". The data is read using a Tokenizer that works on top of oal.analysis.NumericTokenStream from Lucene. This one produces the tokens from the numerical value given as native data type to the TokenStream. Those are indexed (in fact, it is binary data in different precisions according to the precision step).
>> Additional analysis on top of that is not easy possible, because the Tokenizer does all the work, there is no way to inject a TokenFilter. Theoretically, there would only be the possibility to add a CharFilter before the numeric tokenizer. But the field type does not allow to do that at the moment, because the "analysis" is hardcoded in the field type.
>>
>>
>> Uwe
>> -----
>> Uwe Schindler
>> H.-H.-Meier-Allee 63, D-28213 Bremen
>> http://www.thetaphi.de
>> eMail: uwe@thetaphi.de
>>
>>
>>> -----Original Message-----
>>> From: Erick Erickson [mailto:erickerickson@gmail.com]
>>> Sent: Thursday, March 20, 2014 6:52 PM
>>> To: dev@lucene.apache.org
>>> Subject: Analyzing primitive types, why can't we do this in Solr?
>>>
>>> It's bugged me for a while that we can't define any analysis on primitive
>>> types. This is especially acute with date types, we require a very exact format
>>> and have to tell people "transform it correctly on the ingestion side", or
>>> "create an custom update processor that transforms it".
>>>
>>> I thought I remembered something about being able to do this, but can't find
>>> it. I suspect I was confusing it with DIH.
>>>
>>> What's the reason for primitive types being unanalyzed? Just "it's always
>>> been that way", or "it would lead to a very sticky wicket we never wanted to
>>> get stuck in"? Both are perfectly valid, I'm just sayin'.
>>>
>>> I realize this would provide some "interesting" output. Say you defined a
>>> regex for an int type that removed all non-numerics. If the input was
>>> "30asdf" and it was transformed correctly into 30 for the underlying int field,
>>> it would still come back as 30asdf from the stored data, but that's true about
>>> all analysis steps.
>>>
>>> Or perhaps you'd like to have a string of integers as input to a multiValued int
>>> field. Or....
>>>
>>> Musings sparked by seeing this crop up again in another context.
>>>
>>> Erick
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For additional
>>> commands, e-mail: dev-help@lucene.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Analyzing primitive types, why can't we do this in Solr?
Posted by Erick Erickson <er...@gmail.com>.
Uwe:
Thanks! I peeked at the code briefly and I see that it would
be hard.
Figured there was a good reason.
What about a higher-level approach? I'm thinking a thin
wrapper for Solr that would apply the analysis chains and feed
the results into the native Lucene primitive processing. Seems
kind of kludgy, I'm mostly wondering if it's conceptually
possible/reasonable.
Frankly, I'm not convinced there's enough all for something like
this to justify the work/complexification though.
Erick
On Thu, Mar 20, 2014 at 11:17 AM, Uwe Schindler <uw...@thetaphi.de> wrote:
> Hi Erick,
>
> The numerics are in fact "analyzed". The data is read using a Tokenizer that works on top of oal.analysis.NumericTokenStream from Lucene. This one produces the tokens from the numerical value given as native data type to the TokenStream. Those are indexed (in fact, it is binary data in different precisions according to the precision step).
> Additional analysis on top of that is not easy possible, because the Tokenizer does all the work, there is no way to inject a TokenFilter. Theoretically, there would only be the possibility to add a CharFilter before the numeric tokenizer. But the field type does not allow to do that at the moment, because the "analysis" is hardcoded in the field type.
>
>
> Uwe
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: uwe@thetaphi.de
>
>
>> -----Original Message-----
>> From: Erick Erickson [mailto:erickerickson@gmail.com]
>> Sent: Thursday, March 20, 2014 6:52 PM
>> To: dev@lucene.apache.org
>> Subject: Analyzing primitive types, why can't we do this in Solr?
>>
>> It's bugged me for a while that we can't define any analysis on primitive
>> types. This is especially acute with date types, we require a very exact format
>> and have to tell people "transform it correctly on the ingestion side", or
>> "create an custom update processor that transforms it".
>>
>> I thought I remembered something about being able to do this, but can't find
>> it. I suspect I was confusing it with DIH.
>>
>> What's the reason for primitive types being unanalyzed? Just "it's always
>> been that way", or "it would lead to a very sticky wicket we never wanted to
>> get stuck in"? Both are perfectly valid, I'm just sayin'.
>>
>> I realize this would provide some "interesting" output. Say you defined a
>> regex for an int type that removed all non-numerics. If the input was
>> "30asdf" and it was transformed correctly into 30 for the underlying int field,
>> it would still come back as 30asdf from the stored data, but that's true about
>> all analysis steps.
>>
>> Or perhaps you'd like to have a string of integers as input to a multiValued int
>> field. Or....
>>
>> Musings sparked by seeing this crop up again in another context.
>>
>> Erick
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For additional
>> commands, e-mail: dev-help@lucene.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
RE: Analyzing primitive types, why can't we do this in Solr?
Posted by Uwe Schindler <uw...@thetaphi.de>.
Hi Erick,
The numerics are in fact "analyzed". The data is read using a Tokenizer that works on top of oal.analysis.NumericTokenStream from Lucene. This one produces the tokens from the numerical value given as native data type to the TokenStream. Those are indexed (in fact, it is binary data in different precisions according to the precision step).
Additional analysis on top of that is not easy possible, because the Tokenizer does all the work, there is no way to inject a TokenFilter. Theoretically, there would only be the possibility to add a CharFilter before the numeric tokenizer. But the field type does not allow to do that at the moment, because the "analysis" is hardcoded in the field type.
Uwe
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de
> -----Original Message-----
> From: Erick Erickson [mailto:erickerickson@gmail.com]
> Sent: Thursday, March 20, 2014 6:52 PM
> To: dev@lucene.apache.org
> Subject: Analyzing primitive types, why can't we do this in Solr?
>
> It's bugged me for a while that we can't define any analysis on primitive
> types. This is especially acute with date types, we require a very exact format
> and have to tell people "transform it correctly on the ingestion side", or
> "create an custom update processor that transforms it".
>
> I thought I remembered something about being able to do this, but can't find
> it. I suspect I was confusing it with DIH.
>
> What's the reason for primitive types being unanalyzed? Just "it's always
> been that way", or "it would lead to a very sticky wicket we never wanted to
> get stuck in"? Both are perfectly valid, I'm just sayin'.
>
> I realize this would provide some "interesting" output. Say you defined a
> regex for an int type that removed all non-numerics. If the input was
> "30asdf" and it was transformed correctly into 30 for the underlying int field,
> it would still come back as 30asdf from the stored data, but that's true about
> all analysis steps.
>
> Or perhaps you'd like to have a string of integers as input to a multiValued int
> field. Or....
>
> Musings sparked by seeing this crop up again in another context.
>
> Erick
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For additional
> commands, e-mail: dev-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org