[
https://issues.apache.org/jira/browse/LUCENE-2353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shai Erera updated LUCENE-2353:
---
Attachment: LUCENE-2353.patch
Updated to also match 'c:/temp' like paths, which are also accepted on
[
https://issues.apache.org/jira/browse/LUCENE-2324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12851142#action_12851142
]
Michael Busch commented on LUCENE-2324:
---
{quote}
The clarify, the apply deletes doc
[
https://issues.apache.org/jira/browse/LUCENE-2324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12851099#action_12851099
]
Jason Rutherglen commented on LUCENE-2324:
--
{quote}You only need one additional i
[
https://issues.apache.org/jira/browse/LUCENE-2324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12851078#action_12851078
]
Michael Busch commented on LUCENE-2324:
---
{quote}
I'm not sure we need that level of
[
https://issues.apache.org/jira/browse/LUCENE-2184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12851043#action_12851043
]
Grant Ingersoll commented on LUCENE-2184:
-
Committed revision 928860 w/ the patch
[
https://issues.apache.org/jira/browse/LUCENE-2184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Ingersoll updated LUCENE-2184:
Attachment: LUCENE-2184.patch
Here's a patch. All tests still pass.
> CartesianPolyFilte
[
https://issues.apache.org/jira/browse/LUCENE-2324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12851017#action_12851017
]
Jason Rutherglen commented on LUCENE-2324:
--
Michael B.: What you're talking about
[
https://issues.apache.org/jira/browse/LUCENE-2184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Ingersoll reassigned LUCENE-2184:
---
Assignee: Grant Ingersoll
> CartesianPolyFilterBuilder doesn't properly account for
[
https://issues.apache.org/jira/browse/LUCENE-2184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12851013#action_12851013
]
Grant Ingersoll commented on LUCENE-2184:
-
Note, this bug exists for the "min" cas
[
https://issues.apache.org/jira/browse/LUCENE-2354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12851010#action_12851010
]
Uwe Schindler edited comment on LUCENE-2354 at 3/29/10 5:23 PM:
[
https://issues.apache.org/jira/browse/LUCENE-2354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12851010#action_12851010
]
Uwe Schindler commented on LUCENE-2354:
---
bq. But the encoding is unchanged right? (I
[
https://issues.apache.org/jira/browse/LUCENE-2354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12851008#action_12851008
]
Michael McCandless commented on LUCENE-2354:
bq. NumericUtils still contains l
[
https://issues.apache.org/jira/browse/LUCENE-2329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12850989#action_12850989
]
Michael Busch commented on LUCENE-2329:
---
Good catch!
Thanks for the thorough explan
[
https://issues.apache.org/jira/browse/LUCENE-2356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12850928#action_12850928
]
Earwin Burrfoot commented on LUCENE-2356:
-
That's likely orthogonal.
If you want a
>Of course, but what about the Lucene doc id doesn't provide that?
The question being how you determine the correct doc id to use in the first
place (especially when they are know to be volatile) - the current answer is to
use a stable identifier term which your app holds in the index, AKA a pri
[
https://issues.apache.org/jira/browse/LUCENE-2356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12850916#action_12850916
]
Michael McCandless commented on LUCENE-2356:
The above comment was on the wron
[
https://issues.apache.org/jira/browse/LUCENE-2357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12850914#action_12850914
]
Michael McCandless commented on LUCENE-2357:
I won't have any time to take thi
On 2010-03-29 15:11, Uwe Goetzke wrote:
The filed this as patent, too:
http://www.freepatentsonline.com/y2009/0228528.html
.. which is not granted yet, right? It's a patent application. Besides,
I live in EU ;)
--
Best regards,
Andrzej Bialecki <><
___. ___ ___ ___ _ _ __
The filed this as patent, too:
http://www.freepatentsonline.com/y2009/0228528.html
Regards
Uwe Goetzke
-Ursprüngliche Nachricht-
Von: Andrzej Bialecki [mailto:a...@getopt.org]
Gesendet: Montag, 29. März 2010 14:50
An: java-dev@lucene.apache.org
Betreff: Re: Incremental Field Updates
On
On 2010-03-29 12:26, Michael McCandless wrote:
I agree this is a long overdue feature... we need to get it into
Lucene somehow.
I like the Layers analogy... I think that will work well with Lucene's
transactional semantics, ie a prior commit point would continue to see
the index before the updat
On Mar 29, 2010, at 2:26 AM, Mark Harwood wrote:
>
>>
>>> Of course introducing the idea of updates also introduces the notion of a
>>> primary key and there's probably an entirely separate discussion to be had
>>> around user-supplied vs Lucene-generated keys.
>>
>> Not sure I see that need
>>Who ever said that some_condition should point to a unique document?
>
> My assumption was, for now, we were still talking about the simpler case of
> updating a single document.
> If we extend the discussion to support set-based updates it's worth
> considering the common requirements for upda
>Who ever said that some_condition should point to a unique document?
My assumption was, for now, we were still talking about the simpler case of
updating a single document.
If we extend the discussion to support set-based updates it's worth considering
the common requirements for updating set
[
https://issues.apache.org/jira/browse/LUCENE-2356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12850887#action_12850887
]
Michael McCandless commented on LUCENE-2356:
I won't have any time to take thi
Reduce transient RAM usage while merging by using packed ints array for docID
re-mapping
Key: LUCENE-2357
URL: https://issues.apache.org/jira/browse/LUCENE-2357
Enable setting the terms index divisor used by IndexWriter whenever it opens
internal readers
-
Key: LUCENE-2356
URL: https://issues.apache.org/jira/browse/LUCENE-2356
[
https://issues.apache.org/jira/browse/LUCENE-2329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless reopened LUCENE-2329:
Reopening to fix the RAM balancing problems...
> Use parallel arrays instead of Posti
[
https://issues.apache.org/jira/browse/LUCENE-2329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12850884#action_12850884
]
Michael McCandless commented on LUCENE-2329:
I think we need to fix how RAM is
I think that's a good idea for Lucy.
Mike
On Fri, Mar 26, 2010 at 10:58 AM, Marvin Humphrey
wrote:
> On Thu, Mar 25, 2010 at 06:24:34AM -0400, Michael McCandless wrote:
>> > Maybe aggressive automatic data-reduction makes more sense in the context
>> > of
>> > "flexible matching", which is more
On Thu, Mar 25, 2010 at 1:20 PM, Marvin Humphrey wrote:
> On Thu, Mar 25, 2010 at 06:24:34AM -0400, Michael McCandless wrote:
>> >> Also, will Lucy store the original stats?
>> >
>> > These?
>> >
>> > * Total number of tokens in the field.
>> > * Number of unique terms in the field.
>> > * D
I agree this is a long overdue feature... we need to get it into
Lucene somehow.
I like the Layers analogy... I think that will work well with Lucene's
transactional semantics, ie a prior commit point would continue to see
the index before the updates but new commit points would see the
updates.
>>Variant d) sounds most logical? And enables all sorts of fun stuff.
>
> So the duplicate-key docs can have different values for initial-insert fields
> but partial updates will cause sharing of a common field value?
> And subsequent same-key doc inserts do or don't share these previous
> "part
[
https://issues.apache.org/jira/browse/LUCENE-2324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12850864#action_12850864
]
Michael McCandless commented on LUCENE-2324:
bq. Mike, can you explain what t
>Variant d) sounds most logical? And enables all sorts of fun stuff.
So the duplicate-key docs can have different values for initial-insert fields
but partial updates will cause sharing of a common field value?
And subsequent same-key doc inserts do or don't share these previous
"partial-update
[
https://issues.apache.org/jira/browse/LUCENE-2324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12850857#action_12850857
]
Michael McCandless commented on LUCENE-2324:
Yeah I think we're gonna need the
>>If someone needs this, it can be built over lucene, without
>>introducing it as a core feature and needlessly complicating things.
>
> I think with any partial-update feature the *absence* of primary key support
> would "needlessly complicate things":
> If Lucene is not capable of performing du
[
https://issues.apache.org/jira/browse/LUCENE-2351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12850844#action_12850844
]
Michael McCandless commented on LUCENE-2351:
OOOH I like this approach!! It m
>I can delete by lucene-generated docId.
Which users used to have to find by first coding a primary-key-term search.
Delete by term removed this step to make life easier.
>If someone needs this, it can be built over lucene, without
>introducing it as a core feature and needlessly complicating
> Of course introducing the idea of updates also introduces the notion of a
> primary key and there's probably an entirely separate discussion to be had
> around user-supplied vs Lucene-generated keys.
Not sure I see that need. Can you explain your reasoning a bit more?
>>> If you
On 29 Mar 2010, at 07:45, Earwin Burrfoot wrote:
Of course introducing the idea of updates also introduces the notion of a
primary key and there's probably an entirely separate discussion to be had
around user-supplied vs Lucene-generated keys.
Not sure I see that need. Can you explain your re
40 matches
Mail list logo
