Re: When are deletions permanent?
When you close the IndexReader you know the delete is commited to disk. I believe calling the commit method will also guarantee that all changes are written to disk. --- Lucene Users List lucene-user@jakarta.apache.org wrote: Hi everyone, I need to update a document in Lucene. I already know that for that I need to do a delete (IndexReader) and then an add (IndexWriter). I also know that the deletion means been marked as deleted, until optimize(). My question is, when am I SURE that the mark is commited to disk? I mean, suppose that there is a crash while Im doing a deletion. Could it be that when I recover and check Lucene, the item is still there? At which point Im 100% sure the deletion is permanent? What about adds? Thanks, Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Optimize not deleting all files
Ernestor, what version of Lucene are you running? --- Lucene Users List lucene-user@jakarta.apache.org wrote: Hi all We have the same problem. We guess that the problem is that windows lock files. Our enviroment: Windows 2000 Tomcat 5.5.4 Ernesto. [EMAIL PROTECTED] escribiꊾ Hi, When I run an optimize in our production environment, old index are left in the directory and are not deleted. My understanding is that an optimize will create new index files and all existing index files should be deleted. Is this correct? We are running Lucene 1.4.2 on Windows. Any help is appreciated. Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.8.5 - Release Date: 03/02/2005 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Optimize not deleting all files
Yes, I believe my problem is related to open IndexReaders. The issues is that we can't shut down our live search application while we wait for a 10 minute optimization. Search is a major part of our application and removing the feature would significantly affect our end users (even though we run the optimize during the night). After the optimize is completed, I close and re-open the readers so they start reading from the new index files. I'm thinking of adding code to delete all the old files at that point. I presume they will no longer be locked. --- Lucene Users List lucene-user@jakarta.apache.org wrote: Hi Patricio, Is it the case that the old index files are not removed from session to session, or only within the same session? The discussion below pertains to the latter case, that is, where the old index files are used in the same process as the files replacing them. I was having a similar problem, and tracked the source down to IndexReaders not being closed in my application. As far as I can tell, in order for IndexReaders to present a consistent view of an index while changes are being made to it, read-only copies of the index are kept around until all IndexReaders using them are closed. If any IndexReaders are open on the index, IndexWriters first make a copy, then operate on the copy. If you track down all of these open IndexReaders and close them before optimization, all of the old index files should be deleted. (Lucene Gurus, please correct this if I have misrepresented the situation). In my application, I had a bad interaction between IndexReader caching, garbage collection, and incremental indexing, in which a new IndexReader was being opened on an index after each indexing increment, without closing the already-opened IndexReaders. On Windows, operating-system level file locking caused by IndexReaders left open was disallowing index re-creation, because the IndexWriter wasn't allowed to delete the index files opened by the abandoned IndexReaders. In short, if you need to write to an index more than once in a single session, be sure to keep careful track of your IndexReaders. Hope it helps, Steve Patricio Keilty wrote: Hi Otis, tried version 1.4.3 without success, old index files still remain in the directory. Also tried not calling optimize(), and still getting the same behaviour, maybe our problem is not related to optimize() call at all. --p Otis Gospodnetic wrote: Get and try Lucene 1.4.3. One of the older versions had a bug that was not deleting old index files. Otis --- [EMAIL PROTECTED] wrote: Hi, When I run an optimize in our production environment, old index are left in the directory and are not deleted. My understanding is that an optimize will create new index files and all existing index files should be deleted. Is this correct? We are running Lucene 1.4.2 on Windows. Any help is appreciated. Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Optimize not deleting all files
Hi, When I run an optimize in our production environment, old index are left in the directory and are not deleted. My understanding is that an optimize will create new index files and all existing index files should be deleted. Is this correct? We are running Lucene 1.4.2 on Windows. Any help is appreciated. Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Locking issue
No need to address individuals here. Sorry about that. I just respect the knowledge that you and Otis have about Lucene so that's why I was asking you specifically. With the information provided, I have no idea what the issue may be. Running the small sample file that is attached to the original message shows how the issue is generated. It takes less than 5 minutes to occur on both Windows XP and Mac OS X. There certainly is no issue reading and writing to an index at the same time, but only one process can be writing/deleting from the index at a time. That's what I thought. I'm seeing otherwise though. --- Lucene Users List [EMAIL PROTECTED] wrote: On Nov 10, 2004, at 2:17 AM, [EMAIL PROTECTED] wrote: Otis or Erik, do you know if a Reader continously opening should cause the Writer to fail with a Lock obtain timed out error? No need to address individuals here. With the information provided, I have no idea what the issue may be. There certainly is no issue reading and writing to an index at the same time, but only one process can be writing/deleting from the index at a time. Erik --- Lucene Users List [EMAIL PROTECTED] wrote: The attached Java file shows a locking issue that occurs with Lucene. One thread opens and closes an IndexReader. The other thread opens an IndexWriter, adds a document and then closes the IndexWriter. I would expect that this app should be able to happily run without an issues. It fails with: java.io.IOException: Lock obtain timed out Is this expected? I thought a Reader could be opened while a Writer is adding a document. Any help is appreciated. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Locking issue
Hi, With the information provided, I have no idea what the issue may be. Is there some information that I should post that will help determine why Lucene is giving me this error? Thanks. --- Lucene Users List [EMAIL PROTECTED] wrote: On Nov 10, 2004, at 2:17 AM, [EMAIL PROTECTED] wrote: Otis or Erik, do you know if a Reader continously opening should cause the Writer to fail with a Lock obtain timed out error? No need to address individuals here. With the information provided, I have no idea what the issue may be. There certainly is no issue reading and writing to an index at the same time, but only one process can be writing/deleting from the index at a time. Erik --- Lucene Users List [EMAIL PROTECTED] wrote: The attached Java file shows a locking issue that occurs with Lucene. One thread opens and closes an IndexReader. The other thread opens an IndexWriter, adds a document and then closes the IndexWriter. I would expect that this app should be able to happily run without an issues. It fails with: java.io.IOException: Lock obtain timed out Is this expected? I thought a Reader could be opened while a Writer is adding a document. Any help is appreciated. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Locking issue
I added it to Bugzilla like you suggested: http://issues.apache.org/bugzilla/show_bug.cgi?id=32171 Let me know if you see any way to get around this issue. --- Lucene Users List [EMAIL PROTECTED] wrote: Whoops! Looks like my attachment didn't make it through. I'm re-attaching my simple test app. Thanks. --- Erik Hatcher [EMAIL PROTECTED] wrote: On Nov 10, 2004, at 5:48 PM, [EMAIL PROTECTED] wrote: Hi, With the information provided, I have no idea what the issue may be. Is there some information that I should post that will help determine why Lucene is giving me this error? You mentioned posting code - though I don't recall getting an attachment. If you could post it as a Bugzilla issue with your code attached, it would be preserved outside of our mailboxes. If the code is self-contained enough for me to try it, I will at some point in the near future. Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Locking issue
Otis or Erik, do you know if a Reader continously opening should cause the Writer to fail with a Lock obtain timed out error? --- Lucene Users List [EMAIL PROTECTED] wrote: The attached Java file shows a locking issue that occurs with Lucene. One thread opens and closes an IndexReader. The other thread opens an IndexWriter, adds a document and then closes the IndexWriter. I would expect that this app should be able to happily run without an issues. It fails with: java.io.IOException: Lock obtain timed out Is this expected? I thought a Reader could be opened while a Writer is adding a document. Any help is appreciated. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Windows Bug?
Hi,
My understanding is that I can have an IndexReader open for searching
(as long as it doesn't delete) while an IndexWriter is updating the index.
I wrote a simple test app to prove this and it works great on Mac OS
X, Java 1.4.2 and Lucene 1.4.2. It fails on Windows XP, Java 1.4.2 and Lucene
1.4.2. I tried other versions of Lucene and it failed in those too.
This
is the app that fails on Windows:
public static void main(String[] args)
throws Exception {
String indexFolder = /TestIndex;
// add
a document to the index
IndexWriter indexWriter = new IndexWriter
(indexFolder,
new StandardAnalyzer(), true);
Document document =
new Document();
Field field = new Field(foo, bar,
true, true, true)
document.add(field);
indexWriter.addDocument(document);
indexWriter.close();
// open an index reader but don't close it
IndexReader indexReader =
IndexReader.open(indexFolder);
// open
an index writer
indexWriter = new IndexWriter
(indexFolder,
new StandardAnalyzer(), true);
indexWriter.close();
}
On Windows XP
this throws an Exception as soon as it tries to open the IndexWriter after
the IndexReader has been opened.
Here's the stack trace:
Exception in
thread main java.io.IOException: Cannot delete _1.cfs
at org.apache.lucene.store.FSDirectory.create(FSDirectory.java:144)
at org.apache.lucene.store.FSDirectory.getDirectory(FSDirectory.java:105)
at org.apache.lucene.store.FSDirectory.getDirectory(FSDirectory.java:83)
at org.apache.lucene.index.IndexWriter.init(IndexWriter.java:173)
at scratch.TestLuceneLocks.main(TestLuceneLocks.java:17)
Is this a bug?
Thanks.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Windows Bug?
Thanks! I just figured that out. I was passing true by mistake.
--- Lucene
Users List [EMAIL PROTECTED] wrote:
The reason this is failing
is because you are trying to create a new
index in the directory. It works
on *nix file systems because you can
delete an open file on those operating
systems, something you can't do
under Windows.
If you change the
create parameter to false on your second call
everything should work as
you expect it to.
On 8 Nov 2004 18:27:12 -, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Hi,
My understanding
is that I can have an IndexReader open for searching
(as long as it doesn't
delete) while an IndexWriter is updating the index.
I wrote a simple
test app to prove this and it works great on Mac OS
X, Java 1.4.2 and
Lucene 1.4.2. It fails on Windows XP, Java 1.4.2 and Lucene
1.4.2.
I tried other versions of Lucene and it failed in those too.
This
is the app that fails on Windows:
public static void main(String[]
args)
throws Exception {
String indexFolder = /TestIndex;
// add
a document to the index
IndexWriter
indexWriter = new IndexWriter
(indexFolder,
new
StandardAnalyzer(), true);
Document document =
new Document();
Field field = new Field(foo, bar,
true,
true, true)
document.add(field);
indexWriter.addDocument(document);
indexWriter.close();
// open an index reader but
don't close it
IndexReader indexReader =
IndexReader.open(indexFolder);
// open
an index writer
indexWriter = new IndexWriter
(indexFolder,
new StandardAnalyzer(), true);
indexWriter.close();
}
On Windows XP
this throws an Exception as soon as it tries to open the IndexWriter after
the IndexReader has been opened.
Here's the stack trace:
Exception in
thread main java.io.IOException: Cannot delete
_1.cfs
at org.apache.lucene.store.FSDirectory.create(FSDirectory.java:144)
at org.apache.lucene.store.FSDirectory.getDirectory(FSDirectory.java:105)
at org.apache.lucene.store.FSDirectory.getDirectory(FSDirectory.java:83)
at org.apache.lucene.index.IndexWriter.init(IndexWriter.java:173)
at scratch.TestLuceneLocks.main(TestLuceneLocks.java:17)
Is this a bug?
Thanks.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For
additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Locks and Readers and Writers
Ok, I simplified my test case a little... I removed the UNC share which is a remote file share that Windows supports. I have two processes running on the same Windows XP machine. 1) The first process uses an IndexWriter to writes to the index and then closes the IndexWriter. 2) The first process sends a multicast event to the other process. 3) The other process opens an IndexReader. 4) Meanwhile, the first process tries to open the index again to do a write. 5) Often the IndexWriter gets an error: Lock obtain timed out Any advice? Is this only a problem on Windows? Here's the stack trace: java.io.IOException: Lock obtain timed out: [EMAIL PROTECTED]:\WINDOWS\TEMP\lucene-9906f192fb41cc8775cf839213997b7e-commit.lock at org.apache.lucene.store.Lock.obtain(Lock.java:58) at org.apache.lucene.store.Lock$With.run(Lock.java:108) at org.apache.lucene.index.IndexWriter.mergeSegments(IndexWriter.java:501) at org.apache.lucene.index.IndexWriter.maybeMergeSegments(IndexWriter.java:458) at org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:310) --- Lucene Users List [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] writes: Hi Christoph, Thats what I thought. But what I'm seeing is this: - open reader for searching (the reader is opening an index on a remote machine (via UNC) which takes a couple seconds) - meanwhile the other service opens an IndexWriter and adds a document (the index writer determines that it needs to merge so it tries to get a lock. since the reader is still opening, the IO exception is thrown) I believe that increasing the merge factor will reduce the opportunity for this to occur. But it will still occur at some point. I'm not sure what you mean by `opening an index on a remote machine (via UNC)' but have you made sure that lock files are put in the same directory for both processes (see the mailing list archive for details)? Also note, that lucene's locking is known not to work on NFS (also see the list archive). I don't know if it works on SMB mounts. Morus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Locks and Readers and Writers
Hi Christoph, Thats what I thought. But what I'm seeing is this: - open reader for searching (the reader is opening an index on a remote machine (via UNC) which takes a couple seconds) - meanwhile the other service opens an IndexWriter and adds a document (the index writer determines that it needs to merge so it tries to get a lock. since the reader is still opening, the IO exception is thrown) I believe that increasing the merge factor will reduce the opportunity for this to occur. But it will still occur at some point. Thanks. --- Lucene Users List [EMAIL PROTECTED] wrote: Morus Walter wrote: AFAIK you should never open an IndexWriter and an IndexReader at the same time. You should use only one of them at a time but you may open as many IndexSearchers as you like for searching. You cannot open an IndexSearcher without opening an IndexReader (explicitly or implicitly). I should have been more specific. The IndexReader which gets opened by an IndexSearcher will never have any changes to commit. So there will never be a problem with locks. As soon as you use an IndexReader to modify your index (delete doc for example) you should not have another IndexReader or IndexWriter open or you will probably get problems with the locks. Christoph - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Locks and Readers and Writers
Hi, I'm getting: java.io.IOException: Lock obtain timed out I have a writer service that opens the index to delete and add docs. I have a reader service that opens the index for searching only. This error occurs when the reader service opens the index (this takes about 500ms). Meanwhile the writer service tries to open it a couple milliseconds later. The reader service hasn't fully opened the index yet and this exception gets thrown. What are my options? Should I just set the timeout to a higher value? Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
IndexReader / IndexSearcher
I'm opening a new IndexReader for every search request which obviously isn't the best option. If I open a reader can I use the same searcher for multiple requests that are happening simultaneously? If I call close on the searcher will it close for all the instances? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Sorting Info
I'm interested in doing sorting in Lucene. Is there a FAQ or an article that will show me how to do this? I already have my indexing and searching working. Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: When does IndexReader pick up changes?
Thanks for the info! --- Lucene Users List [EMAIL PROTECTED] wrote: AFAIK you don't have to close the writer -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, July 29, 2004 11:17 AM To: [EMAIL PROTECTED] Subject: RE: When does IndexReader pick up changes? Yes, I understand that the IndexReader only picks up changes once it is opened. I'm just trying to determine whether the IndexWriter first needs to be closed or if that is not necessary. --- Lucene Users List [EMAIL PROTECTED] wrote: IndexReader will pick the changes as it is opened. If new documents are added to the index you need to open a new IndexReader in order for it to pick up the changes Aviran -Original Message- From: Stephane James Vaucher [mailto:[EMAIL PROTECTED] Sent: Thursday, July 29, 2004 0:00 AM To: Lucene Users List Subject: Re: When does IndexReader pick up changes? IIRC, if you use a searcher, changes are picked up right away. With a reader, I would expect it should react the same way. disclaimerI'm not a lucene guru, I might be wrong/disclaimer Where I'm less sure is with a FSDirectory, as it uses an internal RAMDirectory. If two separate processes (within the same classloader, FS with same paths are reused) use different FSDirectories, you might notice a flushing behaviour. sv On 28 Jul 2004 [EMAIL PROTECTED] wrote: Hi, Does anyone know if the IndexWriter has to be closed for an IndexReader to pick up the changes? Thanks. --- Lucene Users List [EMAIL PROTECTED] wrote: Hi, If I do this: - open index writer - add document - open reader - search with reader - close reader - close writer Will the reader pick up the document that was added to the index since it was opened after the document was added? Or will it only pick up changes that occur after the index writer is closed? Thanks for the help! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
When does IndexReader pick up changes?
Hi, If I do this: - open index writer - add document - open reader - search - close reader - close writer Will the reader pick up the document that was added to the index since it was opened after the document was added? Or will it only pick up changes that occur after the index writer is closed? Thanks for the help! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: When does IndexReader pick up changes?
Hi, Does anyone know if the IndexWriter has to be closed for an IndexReader to pick up the changes? Thanks. --- Lucene Users List [EMAIL PROTECTED] wrote: Hi, If I do this: - open index writer - add document - open reader - search with reader - close reader - close writer Will the reader pick up the document that was added to the index since it was opened after the document was added? Or will it only pick up changes that occur after the index writer is closed? Thanks for the help! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Powered By Lucene image?
Hi, Are there any powered by Lucene images? I thought there used to be some on the site but I can't find them now. Any help is appreciated! Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Exact match search
Hi, I want to match documents that exactly equal a certain value, not just contain it. If I search for foo in Lucene I get back documents like these: foo foo bar bar foo Is there a way to just get the ones that exactly equal the value I'm searching for? In this case, I want to only return the first document (ex. foo). I have a workaround where I store all the values and then after I get the hits I go through them and skip those that don't match. But this will return result sets of hundreds of documents that I don't need. Help! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Pool of IndexReaders or Pool of Searchers?
Hi, I have multiple threads reading an index. Should they all be using the same IndexReader and using a pool of IndexSearchers? Or should they be using a pool of IndexReaders? Basically, one reader or many? Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Searching for asterisk in a term
Can you recommend an analyzer that doesn't discard '*' or '/'? --- Lucene Users List [EMAIL PROTECTED] wrote: The first thing you'll want to check is that you are using an Analyzer that does not discard that '*' before indexing. StandardAnalyzer, for instance, will discard it. Check one of Erik Hatcher's articles that includes a tool that helps you see what your Analyzer does with the any given text input. You can also use Luke to see what your index contains. Otis --- [EMAIL PROTECTED] wrote: Hi, I'm trying to search for a term that contains an asterisk. This is the field that I indexed: - new Field(testField, Hello *foo bar, true, true, true); I'm trying to find this document by matching '*foo': - new TermQuery(new Term(testField, *me)); I've also tried to escape the * like this: - new TermQuery(new Term(testField, \\*me)); Neither of these queries return this document. Is this type of search possible with Lucene? Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
PhraseQuery with Wildcards?
Hi, Is there any way to do a PhraseQuery with Wildcards? I'd like to search for: MyField:foo bar* I thought I could cobble something together using PhraseQuery and Wildcards but I couldn't get this functionality to work due to my lack of experience with Lucene. Is there a way to do this with Lucene? Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Storing dates as longs
Hi, I'm storing my dates as longs. The longs are converted to strings and padded with zeros. Am I going to run into issues with this? Based on other mailing list postings, I suspect that this may cause the too many boolean queries issue when I search for date ranges. Is this true? What are my options for getting around this issue? Any advice is appreciated. Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
