[jira] Closed: (LUCENE-489) Wildcard Queries with leading "*"

[ http://issues.apache.org/jira/browse/LUCENE-489?page=all ] Otis Gospodnetic closed LUCENE-489: --- > Wildcard Queries with leading "*" > - > > Key: LUCENE-489 > URL: http://issues.apache.org/jira/browse

[jira] Resolved: (LUCENE-489) Wildcard Queries with leading "*"

[ http://issues.apache.org/jira/browse/LUCENE-489?page=all ] Otis Gospodnetic resolved LUCENE-489: - Resolution: Won't Fix You can do this if you create your WildcardQuery's programmatically (i.e. not via QueryParser). Support for that is not in

patch to fix setMaxBufferedDocs

Hi, does anybody see a problem with the attached patch? It fixes the problem that setMaxBufferedDocs(1) has no effect. Regards Daniel -- http://www.danielnaber.de Index: /home/dnaber/.eclipse/LuceneSVN/src/java/org/apache/lucene/index/IndexWriter.java =

RE: Indexing Urls pointing to same content

I'm just a novice but I had to do this recently to store items and attached files. There is a many-to-many relationship between items and attached files. If the relationships change I don't want to reindex the items/attachments. So I added the item documents (with unique key in ID), I added the at

Re: Indexing Urls pointing to same content

I know Lucene is not a web indexer... maybe I explain this bad. I'm asking in how STORE the data, not in how locate it. If two files are the same, using MD5 is my actual approach, then I plan to STORE the content once but is necesary add the two locations. Example: c:\file1 Content: One c:\file2

Re: Handling of colons in QueryParserTokenManager

I just verified the behavior of an embedded ':' and I agree it's a problem that needs to be fixed because it currently silently truncates. foo:bar:baz is parsed as foo:bar foo:bar:baz:what is parsed as foo:bar The parser should either - throw an exception - treat ':' (and everything after) as p

Re: Handling of colons in QueryParserTokenManager

On 1/23/06, Gwyn Carwardine <[EMAIL PROTECTED]> wrote: > the Token Manager's job is to parse into field & value, it shouldn't make > any decisions about the value; that value should get passed intact (complete > with colons and any other special characters) It's more a matter of parsing than philo

Re: [jira] Created: (LUCENE-489) Wildcard Queries with leading "*"

Peter Schäfer (JIRA) wrote: It would be nice to have wildcard queries with a leading wildcard ("?" or "*"). I'm aware that this is a well-known issue, and I do understand the reasons behind it, but try explaining that to our end-users ... :-( I'm sure someone mentioned this a while back, bu

[jira] Created: (LUCENE-489) Wildcard Queries with leading "*"

Wildcard Queries with leading "*" - Key: LUCENE-489 URL: http://issues.apache.org/jira/browse/LUCENE-489 Project: Lucene - Java Type: Wish Components: QueryParser Reporter: Peter Schäfer It would be nice to have wildcard quer

RE: Handling of colons in QueryParserTokenManager

Thanks for your reply Erik (good book by the way) It definitely was producing the error. I was very careful to test before I posted. But now, as you say, it doesn't do it. However, I wonder if I was entering ["Fred" TO "joe"] (note the capital F) because that IS still coming back with HTTP 500 er

[jira] Commented: (LUCENE-488) adding docs with large (binary) fields of 5mb causes OOM regardless of heap size

[ http://issues.apache.org/jira/browse/LUCENE-488?page=comments#action_12363628 ] george washington commented on LUCENE-488: -- Daniel, a combination of : iwriter.setMaxBufferedDocs(2); iwriter.setMergeFactor(2); iwriter.setUseCompo