Hi Team,
the question of how to delete with IndexWriter using doc ids is
currently being discussed on java-user
(http://www.gossamer-threads.com/lists/lucene/java-user/57228), so I
thought this is a good time to mention an idea that I recently had. I'm
planning to work on column-stored fields
We can safely ignore these failed build emails
Nigel is working on switching the Lucene nightly build to a shared
(with other Apache TLPs) hudson build zone. It's not quite working
yet (Lucene build seems to be running as the root user), and these
emails are coming from that new
[
https://issues.apache.org/jira/browse/LUCENE-1136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561334#action_12561334
]
Michael McCandless commented on LUCENE-1136:
Doron, do you plan to commit this
Hi,Michael,
You idea is good! But i have a question and thanks for your help!
How you plan to store a unique ID for each doc? My understanding will be
adding a field(i.e uniqueid) for each doc and the field has one identical
token value.
We can add unique ID as payload for that token before
ConjunctionScorer small (ca. 3.5%) optimization
---
Key: LUCENE-1146
URL: https://issues.apache.org/jira/browse/LUCENE-1146
Project: Lucene - Java
Issue Type: Improvement
Components:
[
https://issues.apache.org/jira/browse/LUCENE-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eks Dev updated LUCENE-1146:
Attachment: ConjuctionScorerInitialization.patch
ConjunctionScorer small (ca. 3.5%) optimization
there is also similar issue that changes initialization in next() and skipTo()
in ConjuctionScorer:
https://issues.apache.org/jira/browse/LUCENE-1146
in this case, Constructor already throws IOException, and speed-up is much
biger, 3.5%-4% on dense Scorers
- Original Message
From: eks
[
https://issues.apache.org/jira/browse/LUCENE-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561375#action_12561375
]
Eks Dev commented on LUCENE-1146:
-
argh.. these were not core tests, all CoreTests pass
[
https://issues.apache.org/jira/browse/LUCENE-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561370#action_12561370
]
Eks Dev commented on LUCENE-1146:
-
Whoops, some tests fail!
ConjunctionScorer small
: If they are no longer actively developing the portion of the code that's
: broken, aren't seeking the new feature, etc, and they stay back on old
: versions... isn't that exactly what we want? They can stay on the old version,
: and new application development uses the newer version.
This
: I guess I am suggesting that instead of maintaining the whole major/minor
: thing (not including file format) that we relax a bit and say that any give
: feature we choose to remove or add has to go through two release cycles, which
: according to your averages, would equal just over 1 year's
I don't think group C is interested in bug fixes. I just don't see
how Lucene is at all useful if the users are encountering any bug -
so they either don't use that feature, or they have already developed
a work-around (or they have patched the code in a way that avoids the
bug, yet is
One more example on this. A lot of work was done on transaction
support. I would argue that this falls way short of what is needed,
since there is no XA transaction support. Since the lucene index
(unless stored in an XA db) is a separate resource, it really needs
XA support in order to be
[
https://issues.apache.org/jira/browse/LUCENE-1136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561470#action_12561470
]
Doron Cohen commented on LUCENE-1136:
-
As soon as 2.3 is out?
add ability to not
[
https://issues.apache.org/jira/browse/LUCENE-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eks Dev updated LUCENE-1146:
Attachment: (was: ConjuctionScorerInitialization.patch)
ConjunctionScorer small (ca. 3.5%)
[
https://issues.apache.org/jira/browse/LUCENE-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eks Dev closed LUCENE-1146.
---
Resolution: Incomplete
Lucene Fields: [New] (was: [Patch Available, New])
not ready, patch too bugy
I humbly disagree about NFS. Arguing about where free time was invested,
or wasted, or inefficient, in an open source project just seems silly.
One of the great benefits is esoteric work that would normally not be
allowed for. NFS is easy. A lot of Lucene users don't care about Lucene.
They
+1 (non-binding)
Tested bin.zip and src.zip on XP:
- md5 sums ok.
- src: ant test - all pass.
- bin: demos ran as expected, browsed the javadocs.
Doron
On Jan 22, 2008 4:41 AM, Michael Busch [EMAIL PROTECTED] wrote:
Hi,
just a reminder: this is a NEW vote. We canceled the first vote because
On Dienstag, 22. Januar 2008, Michael Busch wrote:
just a reminder: this is a NEW vote. We canceled the first vote because
with LUCENE-1144 an issue came up that is now fixed in the artifacts.
I ran the test cases, indexed a small collection and tried to access it
with Luke (my system is
On Jan 22, 2008, at 3:45 PM, Chris Hostetter wrote:
Perhaps the crux of the issue is that we as a community need to become
more willing to crank out major releases ... if we just released
3.0 and
now someone came up with the Magic field type and it's really
magically
and we want to start
Grant Ingersoll wrote:
Does anyone have experience w/ how other open source projects deal with
this?
Use abstract base classes instead of interfaces: they're much easier to
evolve back-compatibly. In Hadoop, for example, we really wish that
Mapper and Reducer were not interfaces and are
[
https://issues.apache.org/jira/browse/LUCENE-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561539#action_12561539
]
Doug Cutting commented on LUCENE-1121:
--
What JVM were these tests run with?
Use
: To paraphrase a dead English guy: A rose by any other name is still the same,
: right?
:
: Basically, all the version number tick saves them from is having to read the
: CHANGES file, right?
Correct: i'm not disagreeing with your basic premise, just pointing out
that it can be done with the
I think there are a lot of applications using Lucene where whether
its lost a bit of data or not is not acceptable.
However, it is probably fine for a web search, or intranet search.
As to your first point, that is why the really great open-source
projects (eclipse, open office) have a
+1
On Jan 22, 2008, at 5:54 PM, Daniel Naber wrote:
On Dienstag, 22. Januar 2008, Michael Busch wrote:
just a reminder: this is a NEW vote. We canceled the first vote
because
with LUCENE-1144 an issue came up that is now fixed in the artifacts.
I ran the test cases, indexed a small
See http://hudson.zones.apache.org/hudson/job/Lucene-trunk/346/changes
--
[...truncated 1434 lines...]
A
contrib/analyzers/src/java/org/apache/lucene/analysis/el/GreekLowerCaseFilter.java
A
robert engels wrote:
I think there are a lot of applications using Lucene where whether
its lost a bit of data or not is not acceptable.
Yeah, and I have one of them. Which is why I would love the support your
talking about. But its not there yet and I am just grateful that i can
get my
[
https://issues.apache.org/jira/browse/LUCENE-794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561566#action_12561566
]
Mark Miller commented on LUCENE-794:
Hows that work coming Michael? I have started
A specific example:
You have a criminal justice system that indexes past court cases.
You do a search for cases involving Joe Smith because you are a judge
and you want to review priors before sentencing. Similar issues with
related cases, case history, etc.
Is it better to return
Michael Busch wrote:
Please vote to officially release the release artifacts located at
http://people.apache.org/~buschmi/staging_area/lucene-2.3.0/ as Lucene
2.3.0.
+1
--
Sami Siren
-
To unsubscribe, e-mail: [EMAIL
See http://lucene.zones.apache.org:8080/hudson/job/Lucene-Nightly/346/changes
--
[...truncated 1175 lines...]
A contrib/xml-query-parser/docs/LuceneContribQuery.dtd.entities.html
A
31 matches
Mail list logo
