I see, thanks, Erick!
I will change some architecture of our application because an IndexWriter will
be kept open when program is running.
Best Regards.
jacky
----- Original Message -----
From: "Erick Erickson" <[EMAIL PROTECTED]>
To: <java-user@lucene.apache.org>
Sent: Thursday, September 07, 2006 9:10 PM
Subject: Re: parameter create in IndexWriter
> See below...
>
> On 9/7/06, jacky <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]>
> > 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: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
>
