none none | 1 May 17:21 2002
Picon

WithinSearch

hi,
some time ago i posted a message about how could be possible implement the within search, the link to the
message is:
http://www.mail-archive.com/lucene-dev <at> jakarta.apache.org/msg01042.html

i hope someone can help me.
Thank you very much.
Bye.
Otis Gospodnetic | 1 May 17:28 2002
Picon

Re: WithinSearch

Would adding new terms to the previous query using AND not work?

Otis

--- none none <korfut <at> lycos.com> wrote:
> hi,
> some time ago i posted a message about how could be possible
> implement the within search, the link to the message is:
>
http://www.mail-archive.com/lucene-dev <at> jakarta.apache.org/msg01042.html
> 
> i hope someone can help me.
> Thank you very much.
> Bye.
> 
> 
> 
> --
> To unsubscribe, e-mail:  
> <mailto:lucene-dev-unsubscribe <at> jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:lucene-dev-help <at> jakarta.apache.org>
> 

__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com
none none | 1 May 17:48 2002
Picon

Re: WithinSearch

hi,
doesn't work because if you add an 'AND nextterm' this will not check if the 'nextterm' is  in the next <n>
words, the only guarantee you have is that 'nextterm' is in the document.

I have just problem re-writing the QueryParser.jj and implementing the 'WithinQueryScorer.java' this
one extends PhraseScorer.java.

We need to re-write just 'protected final float phraseFreq()' method.
This will be something similar to the SloppyPhraseScorer.java implementation, 
with one difference, it should make sure that the 'nextterm' position is bigger than 'previousterm' BUT
Position(nextterm) - Position(previousterm) <= [within number]. 
The SloppyPhraseScorer doesn't care about the order, also the comment in the code say:

The slop is in fact an edit-distance, where the units correspond to
    moves of terms in the query phrase out of position.  For example, to switch
    the order of two words requires two moves (the first move places the words
    atop one another), so to permit re-orderings of phrases, the slop must be
    at least two.

So,
how can we have back an instance of WithinQuery from the QueryParser ?
how we should write the 'phraseFreq()' method handle that check on the positions?

Thank you.
Bye.

--

On Wed, 1 May 2002 08:28:47   
 Otis Gospodnetic wrote:
(Continue reading)

Kelvin Tan | 2 May 02:34 2002

Re: [VOTE] Lucene Sandbox committer nomination

Great! Thanks for the support.

Regards,
Kelvin

----- Original Message -----
From: "Peter Carlson" <carlson <at> bookandhammer.com>
To: "Lucene Developers List" <lucene-dev <at> jakarta.apache.org>
Cc: "Kelvin Tan" <kelvin <at> relevanz.com>
Sent: Wednesday, May 01, 2002 6:46 AM
Subject: Re: [VOTE] Lucene Sandbox committer nomination

> That's 3 + votes.
>
> I will have Kelvin added to the Lucene-Sandbox committer list.
>
> Glad to have you on board Kelvin.
>
> --Peter
>
>
>
> On 4/30/02 3:20 PM, "Eugene Gluzberg" <drag0n2 <at> yahoo.com> wrote:
>
> > +1
> > Have fun
> > ----- Original Message -----
> > From: "Otis Gospodnetic" <otis_gospodnetic <at> yahoo.com>
> > To: "Lucene Developers List" <lucene-dev <at> jakarta.apache.org>
> > Sent: Wednesday, April 24, 2002 11:56 AM
(Continue reading)

Otis Gospodnetic | 2 May 15:03 2002
Picon

Serializable RAMDirectory

Hello,

Is there a reason why we can't make RAMDirectory Serializable?
It's only a markup interface anyway, and some folks are obviously 
serializing their RAMDirectories.  Below is an example of such a 
RAMDirectory and, as you can see, it is nearly identical to
RAMDirectory - 
identical except for implementing Serializable.  Furthermore,
RAMDirectory 
could not be inherited because it is final, so all code has to be 
duplicated.

Any reasons against making RAMDirectory implement Serializable?

Thanks,
Otis

--- Karl ie <karl <at> gan.no> wrote:
> that is a great problem with lucene as it uses a FSDir to store it
> has no 
> sence of transaction handling, for critical indexes i serialize a
> RAMdir to a 
> database blob, so i can performe a rollback if needed, but this is a
> enourmos 
> overhead....

> import java.io.Serializable;
> import java.io.IOException;
> import java.util.Vector;
> import java.util.Hashtable;
(Continue reading)

Eugene Gluzberg | 2 May 16:52 2002
Picon

Re: Serializable RAMDirectory

Also add
 static final long serialVersionUID = 1;

if you going to make any class serializable.

----- Original Message -----
From: "Otis Gospodnetic" <otis_gospodnetic <at> yahoo.com>
To: <lucene-dev <at> jakarta.apache.org>
Sent: Thursday, May 02, 2002 9:03 AM
Subject: Serializable RAMDirectory

> Hello,
>
> Is there a reason why we can't make RAMDirectory Serializable?
> It's only a markup interface anyway, and some folks are obviously
> serializing their RAMDirectories.  Below is an example of such a
> RAMDirectory and, as you can see, it is nearly identical to
> RAMDirectory -
> identical except for implementing Serializable.  Furthermore,
> RAMDirectory
> could not be inherited because it is final, so all code has to be
> duplicated.
>
> Any reasons against making RAMDirectory implement Serializable?
>
> Thanks,
> Otis
>
> --- Karl Øie <karl <at> gan.no> wrote:
> > that is a great problem with lucene as it uses a FSDir to store it
(Continue reading)

Scott Ganyo | 2 May 17:27 2002

RE: Serializable RAMDirectory

Personally, I wouldn't recommend this.  The only thing it does is circumvent
the built-in Serialization protection mechanism.

(It's somewhat akin to immediately slashing the seatbelt of your new care
because someday that belt might keep you from being thrown free of your
fire-enveloped car. ;)

Scott

> -----Original Message-----
> From: Eugene Gluzberg [mailto:drag0n2 <at> yahoo.com]
> Sent: Thursday, May 02, 2002 9:52 AM
> To: Lucene Developers List
> Subject: Re: Serializable RAMDirectory
> 
> 
> Also add
>  static final long serialVersionUID = 1;
> 
> if you going to make any class serializable.
> 
> ----- Original Message -----
> From: "Otis Gospodnetic" <otis_gospodnetic <at> yahoo.com>
> To: <lucene-dev <at> jakarta.apache.org>
> Sent: Thursday, May 02, 2002 9:03 AM
> Subject: Serializable RAMDirectory
> 
> 
> > Hello,
> >
(Continue reading)

Otis Gospodnetic | 2 May 17:52 2002
Picon

RE: Serializable RAMDirectory

I assume you are referring to Eugene's suggestion.
I haven't done much with serialization - are you talking about
serialized object 'versioning' which, I presume, Eugene's suggestion
would eliminate?

Thanks,
Otis

--- Scott Ganyo <scott.ganyo <at> eTapestry.com> wrote:
> Personally, I wouldn't recommend this.  The only thing it does is
> circumvent
> the built-in Serialization protection mechanism.
> 
> (It's somewhat akin to immediately slashing the seatbelt of your new
> care
> because someday that belt might keep you from being thrown free of
> your
> fire-enveloped car. ;)
> 
> Scott
> 
> > -----Original Message-----
> > From: Eugene Gluzberg [mailto:drag0n2 <at> yahoo.com]
> > Sent: Thursday, May 02, 2002 9:52 AM
> > To: Lucene Developers List
> > Subject: Re: Serializable RAMDirectory
> > 
> > 
> > Also add
> >  static final long serialVersionUID = 1;
(Continue reading)

Eugene Gluzberg | 2 May 18:40 2002
Picon

Re: Serializable RAMDirectory

There are benefits and problems to setting the serialVersionUID for
serializable classes.

I usually do it for all my serializable classes to make new versions of
classes compatble with old versions of serialzation. So if people are
serializing the RAMDirectory, and we change the method signatures or fields
in the RAMDirectory for the next release, their serialized versions of
RAMDirectory will not load anymore unless we take care in making them
compatable, and the first step to that is to set the serialVersionUID.

However its only recomended if we really know what we are doing. Any time
you change the class after setting the serialVersionUID, you HAVE to make
sure that it REALLY is compatable. For instance if you add any new fields to
the class and you intend to make that new class backwards compatable for
serialization, every method that uses the new field has to assume that its
possible for that new field to be null at the start of the method.

Serial version uid only refers to the specific class. Even if two different
classes have the same serial version uid, they are only compatable if they
have the same name and package (class Hello with serialVersionUID of 1 is
not compatable with class Goodbye with serialVersionUID of 1).

It is a risky thing to do, but without that new versions of the class simply
wont load the old versions.

Up to you guys to descide.
In either case I am up for making the RAMDirectory serializable

----- Original Message -----
From: "Scott Ganyo" <scott.ganyo <at> eTapestry.com>
(Continue reading)

Roman Rokytskyy | 2 May 18:45 2002
Picon

RE: Serializable RAMDirectory

cannot we use readObject and writeObject methods to ensure correct
serialization?

Roman

_________________________________________________________
Do You Yahoo!?
Get your free  <at> yahoo.com address at http://mail.yahoo.com

Gmane