On Wed, Aug 29, 2012 at 4:18 PM, Benson Margulies wrote:
> If I'm following, you've created a division of labor between setReader and
> reset.
Thats not true. setReader shouldnt be doing any labor. its really only
a setter!
One possibility here is to make it final (though its not obvious to me
t
Hi,
> To me, it seemed natural to overload #setReader so that our tokenizer was in a
> consistent state once it was called. It occurs to me to wonder about
> order: if #reset is called before #setReader, I'm up creek unless I copy my
> reset
> implementation into a local override of #setReader.
If I'm following, you've created a division of labor between setReader and
reset.
We have a tokenizer that has a good deal of state, since it has to split
the input into chunks. If I'm following here, you'd recommend that we do
nothing special in setReader, but have #reset fix up all the state on
Yeah, make setReader() final in TokenStream. CharTokenizer must do this
resetting in reset(). This is a similar problem like in good old
StandardTokenizer which called reset() inside setReader(Reader) [at that time
reset(Reader)]. But the latter was fixed already.
-
Uwe Schindler
H.-H.-Meie
On Wed, Aug 29, 2012 at 3:58 PM, Benson Margulies wrote:
> I think I'm beginning to get the idea. Is the following plausible?
>
> At the bottom of the stack, there's an actual source of data -- like a
> tokenizer. For one of those, reset() is a bit silly, and something like
> setReader is the brai
On Wed, Aug 29, 2012 at 3:54 PM, Benson Margulies wrote:
> Some interlinear commentary on the doc.
>
> * Resets this stream to the beginning.
>
> To me this implies a rewind. As previously noted, I don't see how this
> works for the existing implementations.
its not a rewind. the javadocs here
I think I'm beginning to get the idea. Is the following plausible?
At the bottom of the stack, there's an actual source of data -- like a
tokenizer. For one of those, reset() is a bit silly, and something like
setReader is the brains of the operation.
Some number of other components may be stacke
Some interlinear commentary on the doc.
* Resets this stream to the beginning.
To me this implies a rewind. As previously noted, I don't see how this
works for the existing implementations.
* As all TokenStreams must be reusable,
* any implementations which have state that needs to be re
On Wed, Aug 29, 2012 at 3:45 PM, Benson Margulies wrote:
> On Wed, Aug 29, 2012 at 3:37 PM, Robert Muir wrote:
>
>> ok, lets help improve it: I think these have likely always been confusing.
>>
>> before they were both reset: reset() and reset(Reader), even though
>> they are unrelated. I thought
On Wed, Aug 29, 2012 at 3:37 PM, Robert Muir wrote:
> ok, lets help improve it: I think these have likely always been confusing.
>
> before they were both reset: reset() and reset(Reader), even though
> they are unrelated. I thought the rename would help this :)
>
> Does the TokenStream workfloat
ok, lets help improve it: I think these have likely always been confusing.
before they were both reset: reset() and reset(Reader), even though
they are unrelated. I thought the rename would help this :)
Does the TokenStream workfloat here help?
http://lucene.apache.org/core/4_0_0-BETA/core/org/ap
I've read the javadoc through a few times, but I confess that I'm still
feeling dense.
Are all tokenizers responsible for implementing some way of retaining the
contents of their reader, so that a call to reset without a call to
setReader rewinds? I note that CharTokenizer doesn't implement #reset
On Mon, Aug 27, 2012 at 8:31 PM, pranshu sharma wrote:
> Hi there,
>
> I had a question about migrating the coord value one level up. My current
> query structure has a root BooleanQuery with a bunch of nested BooleanQuery
> children: one of these looks for all terms in the query issued, and I wan
http://svn.apache.org/viewvc/lucene/dev/branches/branch_4x/lucene/core/src/java/org/apache/lucene/analysis/package.html?r1=1378591&r2=1378590&pathrev=1378591
On Wed, Aug 29, 2012 at 10:35 AM, Robert Muir wrote:
> sure. you need to wrap the reader in Analyzer.initReader() to do this:
>
> /**
>
On Wed, Aug 29, 2012 at 10:42 AM, Robert Muir wrote:
> Right and what does the @deprecated message say :)
>
Yes, indeed, sorry. I got caught in a maze of twisty passages and my brain
turned off. I'm better now.
>
> On Wed, Aug 29, 2012 at 10:40 AM, Benson Margulies
> wrote:
> > Hang on:
> >
>
Yeah I deprecated that originally when I first started the work on
migrating the Analysis Factories, to reduce the upgrade load.
On Thu, Aug 30, 2012 at 2:40 AM, Benson Margulies wrote:
> Hang on:
>
> [deprecation] org.apache.solr.util.plugin.ResourceLoaderAware in
> org.apache.solr.util.plugin h
Right and what does the @deprecated message say :)
On Wed, Aug 29, 2012 at 10:40 AM, Benson Margulies wrote:
> Hang on:
>
> [deprecation] org.apache.solr.util.plugin.ResourceLoaderAware in
> org.apache.solr.util.plugin has been deprecated
>
>
>
> On Wed, Aug 29, 2012 at 10:30 AM, Robert Muir wro
Hang on:
[deprecation] org.apache.solr.util.plugin.ResourceLoaderAware in
org.apache.solr.util.plugin has been deprecated
On Wed, Aug 29, 2012 at 10:30 AM, Robert Muir wrote:
> On Wed, Aug 29, 2012 at 10:27 AM, Benson Margulies
> wrote:
> > I'm confused. Isn't inform/ResourceLoader deprecate
sure. you need to wrap the reader in Analyzer.initReader() to do this:
/**
* Override this if you want to add a CharFilter chain.
*/
protected Reader initReader(String fieldName, Reader reader) {
return reader;
}
by default it returns the original Reader unchanged.
There are exam
On Wed, Aug 29, 2012 at 10:30 AM, Robert Muir wrote:
> On Wed, Aug 29, 2012 at 10:27 AM, Benson Margulies
> wrote:
> > I'm confused. Isn't inform/ResourceLoader deprecated? But your example
> use
> > it?
> >
>
> Where is it deprecated? What does the deprecation message say?
>
I see. It moved fr
On Wed, Aug 29, 2012 at 10:27 AM, Benson Margulies wrote:
> I'm confused. Isn't inform/ResourceLoader deprecated? But your example use
> it?
>
Where is it deprecated? What does the deprecation message say?
--
lucidworks.com
-
I'm close to the bottom of my list here.
I've got an Analyzer that, in 3.1, set up a CharFilter in the tokenStream
method. So now I have to migrate that to createComponents. Can someone give
me a shove in the right direction?
I'm confused. Isn't inform/ResourceLoader deprecated? But your example use
it?
On Wed, Aug 29, 2012 at 10:20 AM, Robert Muir wrote:
> On Wed, Aug 29, 2012 at 10:10 AM, Benson Margulies
> wrote:
> > Our Solr 3.x code used init(ResourceLoader) and then called the loader to
> > read a file.
> >
>
That's what I meant, thanks.
On Wed, Aug 29, 2012 at 10:20 AM, Robert Muir wrote:
> On Wed, Aug 29, 2012 at 10:10 AM, Benson Margulies
> wrote:
> > Our Solr 3.x code used init(ResourceLoader) and then called the loader to
> > read a file.
> >
> > What's the new approach to reading content from
On Wed, Aug 29, 2012 at 10:10 AM, Benson Margulies wrote:
> Our Solr 3.x code used init(ResourceLoader) and then called the loader to
> read a file.
>
> What's the new approach to reading content from files in the 'usual place'?
I'm not aware of init(ResourceLoader), only inform(ResourceLoader).
Our Solr 3.x code used init(ResourceLoader) and then called the loader to
read a file.
What's the new approach to reading content from files in the 'usual place'?
Replace with BytesRef (https://issues.apache.org/jira/browse/LUCENE-4122)
I'll add a note to MIGRATE.txt about this.
On Wed, Aug 29, 2012 at 9:46 AM, Benson Margulies wrote:
> I'm failing to find advice in MIGRATE.txt on how to replace 'new
> Payload(...)' in migrating to 4.0. What am I missing
I'm failing to find advice in MIGRATE.txt on how to replace 'new
Payload(...)' in migrating to 4.0. What am I missing?
28 matches
Mail list logo
