Hi,
In my application,I wanna sort out index based on different column names in
ascending or descending order
but it doesn't do correctly
For example:
it does well as its column contains single word or phrase
but in the phrase type contains differnet links like .html or .doc or .xls
it
Hi devanadan,
deva_java wrote:
In my application,I wanna sort out index based on different column names in
ascending or descending order but it doesn't do correctly
For example:
it does well as its column contains single word or phrase but in the
phrase type contains differnet links like
[
https://issues.apache.org/jira/browse/LUCENE-843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless updated LUCENE-843:
--
Attachment: LUCENE-843.take4.patch
Another rev of the patch. All tests pass except
I don't think anyone followed-up on this. I think I prefer our current
approach, where contributors provide patches, everyone is free to review and
comment on them, and commiters finally commit it. Feels a bit slower than
commit first, review second, but I think that makes it easier to
I checked and there are escape sequences in there. If it was ever
debatable, I think that tips it in favor of SAX. xerces? The
contrib/gdata stuff seems to use it.
I suppose if I'm careful and creative enough, we could share a lot of
the code amongst benchmark ingesters that use XML, should there
Yes, indeed. May not be necessary initially, but we could support
XPath or something down the road to allow us to specify what things
I wouldn't worry about generalizing too much
to start with. Once we have a couple collections then we can go that
route.
My thoughts, too.
I've been
MemoryCachedRangeFilter to boost performance of Range queries
-
Key: LUCENE-855
URL: https://issues.apache.org/jira/browse/LUCENE-855
Project: Lucene - Java
Issue Type: Improvement
[
https://issues.apache.org/jira/browse/LUCENE-855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Liu updated LUCENE-855:
Attachment: MemoryCachedRangeFilter.patch
Patch produced from latest from SVN
MemoryCachedRangeFilter to
On Apr 2, 2007, at 2:50 PM, Steven Parkes wrote:
On the one hand, creating separate per-article files is clean in
that
when you then ingest, you only have disk i/o that's going to affect
the
ingest performance (as opposed to, say, uncompressing/parsing). On the
other hand, that's a lot of
I noticed some contrib/benchmark files have DOS-style line endings. Tried
this, but failed:
$ svn propset svn:eol-style native
./src/java/org/apache/lucene/benchmark/byTask/tasks/SearchTravTask.java
subversion/libsvn_wc/props.c:1460: (apr_err=29)
svn: File
I think you need to make the files consistent first, something like
dos2unix or unix2dos should do this, if they're available on your
machine.
-Original Message-
From: Otis Gospodnetic [mailto:[EMAIL PROTECTED]
Sent: Monday, April 02, 2007 3:47 PM
To: java-dev@lucene.apache.org
Subject:
Yeah, I was just wondering if there was a SVN-only trick to get that propset
working. Anyhow, this did the trick:
find . -name \*java -type f | xargs perl -pi -e 's/(\r\n|\n|\r)/\n/g'
find . -name \*java -type f | xargs svn propset svn:eol-style native
Otis
P.S.
Doron: I just happened to see
Otis Gospodnetic [EMAIL PROTECTED] wrote on 02/04/2007 16:35:42:
Yeah, I was just wondering if there was a SVN-only trick to get that
propset working. Anyhow, this did the trick:
find . -name \*java -type f | xargs perl -pi -e 's/(\r\n|\n|\r)/\n/g'
find . -name \*java -type f | xargs svn
13 matches
Mail list logo
