lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erick Erickson" <erickerick...@gmail.com>
Subject Re: parameter create in IndexWriter
Date Thu, 07 Sep 2006 13:10:03 GMT
See below...

On 9/7/06, jacky <jackychenp@gmail.com> wrote:
>
>     I am afraid i don't understand it.
>     Input the wrong path? This will be happen rarely since the index path
> is always
> hard code in the config file.


In your application maybe. but not the general case. In any case, this is
one of those design decisions that one can argue with, but that doesn't do
much good, since it works the way it does.

What complexity? What's wrong with

IndexWriter writer = new IndexWriter(<path to directory>, analyzer, !
IndexReader.indexExists(<path to directory>));

This does exactly what you want without creating potential problems by
having assumptions buiilt into Lucene that will trip up others.

    And usually, users need to create a brand new index, and then append the
> new document
> into it.


I disagree. This is an assumption that *you* are making in your particular
problem space, and may or may not have any applicability to others. Lucene
had to be designed in a more general-purpose fashion.

Personally, I'd faaaaaaar rather get an IO exception that I had to deal with
immediately than spend hours/days wondering why my application didn't work
when the configuration file had a typo. Or I transfered an index to a new
machine and didn't get the path right. Or didn't even know that there *was*
a configuration file that I had to match. Or didn't know that someone else
changed the config file while testing and didn't change it back. Or have my
big release occur for my customer and have it not be correct because I
created a new index when I meant to append to an old one (for one of the
above reasons, perhaps). Then have to figure out how to combine the indexes
because I now have the old index somewhere and a separate new index that I
really didn't want.

I don't want this kind of headache built into the tool. If I choose to make
it part of my application, that's my problem, but not something I want
imposed upon me.

 Especially when the solution is so straight-forward.

As you can probably tell, I've spent waaaaay too much time chasing down
really stupid errors that I've made and I'd rather have things blow up
immediately than fail subtly.

Best
Erick

     Best Regards.
>        jacky
>
> ----- Original Message -----
> From: "Daniel Noll" <daniel@nuix.com.au>
> To: <java-user@lucene.apache.org>
> Sent: Thursday, September 07, 2006 2:23 PM
> Subject: Re: parameter create in IndexWriter
>
>
> > jacky wrote:
> > > hi,
> > >    Today I found a funny thing, if "create" parameter in IndexWriter
> set false,
> > > and there is no index Segements in the Directory before, then an
> IOException will be
> > > thrown.
> > >    I am confused that why not using this logic : if there is a
> Segments, then append it, create it otherwise.
> > >    I know we can do this in the application, but it is complex
> sometimes.
> >
> > The reason is that if we don't *want* to create a new text index (e.g.
> > if the user enters the wrong path to the data) then it shouldn't be
> > created automatically because it would result in trash ending up all
> > over the hard disk.
> >
> > Daniel
> >
> >
> > --
> > Daniel Noll
> >
> > Nuix Pty Ltd
> > Suite 79, 89 Jones St, Ultimo NSW 2007, Australia    Ph: +61 2 9280 0699
> > Web: http://www.nuix.com.au/                        Fax: +61 2 9212 6902
> >
> > This message is intended only for the named recipient. If you are not
> > the intended recipient you are notified that disclosing, copying,
> > distributing or taking any action in reliance on the contents of this
> > message or attachment is strictly prohibited.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: java-user-help@lucene.apache.org
> >

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message