RE: new Lucene release: 1.2 RC2

2001-10-22 Thread Doug Cutting

 From: Sunil Zanjad [mailto:[EMAIL PROTECTED]]

   Indexes left in an inconsistent state on crash (i don't
remember who
 
   I believe that even I have reported it. This happens on 
 abrupt exit of the JVM
   To do this I had one thread updating a directory containing 
 many .txt files and
   I simply exited the program. Later when I ran the search, 
 it didnt give me the desired output.

That's actually the correct behavior.  If indexing is not completed, with a
call to IndexWriter.close(), then the index should appear unchanged.

Doug



Re(2): newbi question

2001-10-22 Thread Andrew Cottrell

[EMAIL PROTECTED] writes:
 public class Search {
   public static void main(String[] args) {
  try{
 String indexPath = d:\\org, queryString = parag;
 Searcher searcher = new IndexSearcher(indexPath);

 Hm, are you sure it should be two slashes?  Alternately, try using
forward-slashes (java will map // to whatever your system uses, but not
necessarily \\).

Two back-slashes is correct, the first being the Java escape character.

Should the path passed to IndexSearcher have a trailing back-slash?

i.e. 

public class Search {
  public static void main(String[] args) {
try{
  String indexPath = d:\\org\\, queryString = parag;
  Searcher searcher = new IndexSearcher(indexPath);

Regards,
-Andrew Cottrell




RE: Context specific summary with the search term

2001-10-22 Thread Doug Cutting

 From: Lee Mallabone [mailto:[EMAIL PROTECTED]]
 
 I'm trying to implement this and should be able to contribute any
 succesful results, but I need to produce context on a per-field basis.
 Eg. if I got a token hit in the text body of a document, but the first
 hit token was a word in the section title, I'd want to 
 generate context
 around the token in the text body.

How did the title ever get indexed as the title?  Presumably you split the
document into fields when it was indexed.  Similarly, if you re-tokenize
things a field at a time then you should always know which field you are in,
no?

 I had been using a TokenStream to try this. However, lucene's Token
 class doesn't seem to have any concept of fields, (even when I
 tokenStream() a document that is in the index with a whole bunch of
 fields). Is there any reason for this? Moreover, any 
 suggestions of how
 to find the information I need?
 
 The natural thing seems to be to have a field-aware token stream, but
 I'm not sure how I'd go about implementing that...
 
 Regards,
 
 -- 
 Lee Mallabone
 



RE: new Lucene release: 1.2 RC2

2001-10-22 Thread Sunil Zanjad

 From: Sunil Zanjad [mailto:[EMAIL PROTECTED]]

   Indexes left in an inconsistent state on crash (i don't
remember who

   I believe that even I have reported it. This happens on
 abrupt exit of the JVM
   To do this I had one thread updating a directory containing
 many .txt files and
   I simply exited the program. Later when I ran the search,
 it didnt give me the desired output.

That's actually the correct behavior.  If indexing is not completed, with
a
call to IndexWriter.close(), then the index should appear unchanged.

Doug

But what happens to those files which I have indexed successfully earlier?
The search wouldnt retrieve results of the previous indexed files.
Is this state correct?
Please do clarify on this.

Regards,

Sunil Zanjad




RE: new Lucene release: 1.2 RC2

2001-10-22 Thread Sunil Zanjad

Hi,

Two weeks back I did have the problem which I stated.
But I am unable to reproduce the results currently. I tested and retested
but couldnt repeat the same.
Doug have U guys fixed the issue long back itself ?
(The only thing I have done fresh is to download the latest
lucene-1.2-rc1.zip file and re-installed lucene  - since it came along with
source code)

:-)

Regards,

Sunil Zanjad


-Original Message-
From: Doug Cutting [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, October 23, 2001 1:48 AM
To: '[EMAIL PROTECTED]'; 'Scott Ganyo'; [EMAIL PROTECTED]
Subject: RE: new Lucene release: 1.2 RC2


If you think there is a bug, can you please provide a simple,
self-contained, reproducible test case that illustrates the problem.  You
could use Runtime.getRuntime().halt() to abruptly exit the JVM.

Thanks,

Doug


 -Original Message-
 From: Sunil Zanjad [mailto:[EMAIL PROTECTED]]
 Sent: Monday, October 22, 2001 12:49 PM
 To: Doug Cutting; 'Scott Ganyo'; [EMAIL PROTECTED]
 Subject: RE: new Lucene release: 1.2 RC2


  From: Sunil Zanjad [mailto:[EMAIL PROTECTED]]
 
Indexes left in an inconsistent state on crash (i don't
 remember who
 
I believe that even I have reported it. This happens on
  abrupt exit of the JVM
To do this I had one thread updating a directory containing
  many .txt files and
I simply exited the program. Later when I ran the search,
  it didnt give me the desired output.

 That's actually the correct behavior.  If indexing is not
 completed, with
 a
 call to IndexWriter.close(), then the index should appear unchanged.

 Doug

 But what happens to those files which I have indexed
 successfully earlier?
 The search wouldnt retrieve results of the previous indexed files.
 Is this state correct?
 Please do clarify on this.

 Regards,

 Sunil Zanjad





Re: new Lucene release: 1.2 RC2

2001-10-22 Thread Steven J. Owens

Sunil,

 Two weeks back I did have the problem which I stated.
 But I am unable to reproduce the results currently. I tested and retested
 but couldnt repeat the same.
 Doug have U guys fixed the issue long back itself ?
 (The only thing I have done fresh is to download the latest
 lucene-1.2-rc1.zip file and re-installed lucene  - since it came along with
 source code)

 I believe what Sunil was trying to describe was:

a) sucessfully created index
b) did searches on index
c) started to update index
d) clicked exit from app before updating completed
e) ran app again 
f) could not repeat searches from step b.

 Doug has recently mentioned several improvements in the past
month or so.  I'm looking forward to moving over to the new version,
which is among other things thread safe.  This sounds like the area
where you were probably having problems, which means it's likely that
Doug's changes fixed it.

 This is, by the way, why it's important to report problems
early, ideally along with test data and code to reproduce it, or at
least detailed descriptions of how to reproduce it...

Steven J. Owens
[EMAIL PROTECTED]