[
https://issues.apache.org/jira/browse/LUCENE-914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12629115#action_12629115
]
Michael McCandless commented on LUCENE-914:
---
How about we change the spec for all
[
https://issues.apache.org/jira/browse/LUCENE-1357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12629117#action_12629117
]
Michael McCandless commented on LUCENE-1357:
Mark, do you have a concrete patc
[
https://issues.apache.org/jira/browse/LUCENE-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12629125#action_12629125
]
Shai Erera commented on LUCENE-1131:
I agree with the body, that's what I had in mind.
[
https://issues.apache.org/jira/browse/LUCENE-1357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12629127#action_12629127
]
Mark Miller commented on LUCENE-1357:
-
Ill put it up today...just wanted to make sure
[
https://issues.apache.org/jira/browse/LUCENE-914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12629130#action_12629130
]
Paul Elschot commented on LUCENE-914:
-
I had another look at these lines in Disjunction
Hi Joaquin,
Using HBase with realtime Lucene would be in line with what Google
does. However the question is whether or not this is completely
necessary or the most simple approach. That probably can only be
answered by doing a live comparison of the two! Unfortunately that
would require probab
[
https://issues.apache.org/jira/browse/LUCENE-914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12629137#action_12629137
]
Paul Elschot commented on LUCENE-914:
-
Well, how about changing the TermDocs interface
SpanScorer fails when sloppyFreq() returns 0
Key: LUCENE-1379
URL: https://issues.apache.org/jira/browse/LUCENE-1379
Project: Lucene - Java
Issue Type: Bug
Components: Search
[
https://issues.apache.org/jira/browse/LUCENE-914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12629133#action_12629133
]
Doron Cohen commented on LUCENE-914:
{quote}
... else what happens is undefined ...
{qu
[
https://issues.apache.org/jira/browse/LUCENE-914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12629130#action_12629130
]
[EMAIL PROTECTED] edited comment on LUCENE-914 at 9/8/08 4:20 AM:
---
[
https://issues.apache.org/jira/browse/LUCENE-914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12629142#action_12629142
]
Paul Elschot commented on LUCENE-914:
-
See LUCENE-1379 for the SpanScorer bug when slop
[
https://issues.apache.org/jira/browse/LUCENE-1379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Elschot updated LUCENE-1379:
-
Attachment: LUCENE-1379.patch
The patch of 20080908 compiles, but it is untested because of
[
https://issues.apache.org/jira/browse/LUCENE-1357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Miller updated LUCENE-1357:
Attachment: LUCENE-1357.patch
> SpanScorer does not respect ConstantScoreRangeQuery setting
>
[
https://issues.apache.org/jira/browse/LUCENE-914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12629133#action_12629133
]
doronc edited comment on LUCENE-914 at 9/8/08 4:38 AM:
{quote}
[
https://issues.apache.org/jira/browse/LUCENE-1279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12629131#action_12629131
]
Michael McCandless commented on LUCENE-1279:
Grant, what's the game plan on th
[
https://issues.apache.org/jira/browse/LUCENE-914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12629157#action_12629157
]
Yonik Seeley commented on LUCENE-914:
-
bq. How about we change the spec for all skipTo'
[
https://issues.apache.org/jira/browse/LUCENE-914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12629164#action_12629164
]
Michael McCandless commented on LUCENE-914:
---
Since we're still having healthy dis
[
https://issues.apache.org/jira/browse/LUCENE-1327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless updated LUCENE-1327:
---
Fix Version/s: (was: 2.4)
We're still iterating on the approach to resolve this,
Hi,
We experimented using HBase's scalable infrastructure to scale out Lucene:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg01143.html
There is the concern on the impact of HDFS's random read performance
on Lucene search performance. And we can discuss if HBase's architecture
is best for scal
Ning Li wrote:
I agree with Otis that the first step for Lucene is probably to
support real-time
search. The instantiated index in contrib seems to be something close..
Maybe we should start fleshing out what we want in realtime search on
the wiki?
Could it be as simple as making Instantiated
InstantiatedIndex isn't quite realtime. Instead a new
InstantiatedIndex is created per transaction in Ocean and managed
thereafter. This however is fairly easy to build and could offer
realtime in Lucene without adding the transaction logging. It would
be good to find out what scope is acceptabl
I'd also trying to make time to explore the approach of creating an
IndexReader impl. that searches IndexWriter's RAM buffer.
I think it's quite feasible, but, it'd still have a "reopen" cost in
that any buffered delete by term or query would have to be
"materialiazed" into docIDs on reop
On Mon, Sep 8, 2008 at 12:33 PM, Michael McCandless
<[EMAIL PROTECTED]> wrote:
> I'd also trying to make time to explore the approach of creating an
> IndexReader impl. that searches IndexWriter's RAM buffer.
That seems like it could possibly be the best performing approach in
the long run.
> I t
I need to point out that the only thing I know InstantiatedIndex to be
great at is read access in the inverted index. It consumes a lot more
heap than RAMDirectory and InstantiatedIndexWriter is slightly less
efficient than IndexWriter.
Please let me know if your experience differs from the
Yonik Seeley wrote:
I think it's quite feasible, but, it'd still have a "reopen" cost
in that
any buffered delete by term or query would have to be
"materialiazed" into
docIDs on reopen. Though, if this somehow turns out to be a
problem, in the
future we could do this materializing immedi
On Mon, Sep 8, 2008 at 2:43 PM, Yonik Seeley <[EMAIL PROTECTED]> wrote:
> But, how would you maintain a static view of an index...?
>
> IndexReader r1 = indexWriter.getCurrentIndex()
> indexWriter.addDocument(...)
> IndexReader r2 = indexWriter.getCurrentIndex()
>
> I assume r1 will have a view of
On Mon, Sep 8, 2008 at 3:56 PM, Ning Li <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 8, 2008 at 2:43 PM, Yonik Seeley <[EMAIL PROTECTED]> wrote:
>> But, how would you maintain a static view of an index...?
>>
>> IndexReader r1 = indexWriter.getCurrentIndex()
>> indexWriter.addDocument(...)
>> IndexRead
That sounds about correct and I don't think it matters much. I keep
the documents by default stored in InstantiatedIndex to 100. So the
heap size doesn't become a problem.
On Mon, Sep 8, 2008 at 2:58 PM, Karl Wettin <[EMAIL PROTECTED]> wrote:
> I need to point out that the only thing I know Inst
Term dictionary? I'm curious how that would be solved?
On Mon, Sep 8, 2008 at 3:04 PM, Michael McCandless
<[EMAIL PROTECTED]> wrote:
>
> Yonik Seeley wrote:
>
>>> I think it's quite feasible, but, it'd still have a "reopen" cost in that
>>> any buffered delete by term or query would have to be "m
On Mon, Sep 8, 2008 at 3:04 PM, Michael McCandless
<[EMAIL PROTECTED]> wrote:
> Right, getCurrentIndex would return a MultiReader that includes
> SegmentReader for each segment in the index, plus a "RAMReader" that
> searches the RAM buffer. That RAMReader is a tiny shell class that would
> basica
Perhaps an interesting project would be to integrate Ocean with H2
www.h2database.com to take advantage of both models. I'm not sure how
exactly that would work, but it seems like it would not be too
difficult. Perhaps this would solve being able to perform faster
hierarchical queries and perhaps
Yes, both Marcelo and I would be interested.
We looked into H2 and it looks like something similar to Oracle's ODCI can
be implemented. Plus the primitive full-text implementación is based on
Lucene.
I say primitive because looking at the code I saw that one cannot define an
Analyzer and for each
:
: Is there a good place to place the javadocs on the Apache website once they
are more complete?
generated javadocs aren't really neccessary (at least not at this stage)
just having javadoc comments in the code makes it a lot easier to review
new contributions and patches (most people revi
Cool. I mention H2 because it does have some Lucene code in it yes.
Also according to some benchmarks it's the fastest of the open source
databases. I think it's possible to integrate realtime search for H2.
I suppose there is no need to store the data in Lucene in this case?
One loses the multi
Hi:
Integrating Lucene in a RDBMS has two separate concern:
- Integrate it as index to receive notification when a row change
and that the optimizer can choose a right execution plan based on the
index statistics.
- Replace Lucene file system store to align database changes with
Lucene changes,
I am wondering if in an integrated solution, things like sorting still
require the field cache? What if untokenized fields could be stored
in H2, normal tokenized fields in Lucene. Then somehow make the query
work properly. Yes the rowid would need to be stored. Currently
Lucene range queries a
> I am wondering if in an integrated solution, things like sorting still
> require the field cache? What if untokenized fields could be stored
> in H2, normal tokenized fields in Lucene. Then somehow make the query
> work properly. Yes the rowid would need to be stored. Currently
> Lucene range
37 matches
Mail list logo
