: Just out of curiousity, does Lucene hold onto a RAMDirectory instance
: somewhere after it has called close on it? If so, that would have been
: the ideal place to fix it any kind of "leak".
Not that I'm aware of. In my opinion there was no leak, i was just trying
to make RAMDirectory.close()
On Jul 8, 2006, at 9:46 AM, Chuck Williams wrote:
Many things would be cleaner in Lucene if fields had a global
semantics,
i.e., if properties like text vs. binary, Index, Store, TermVector,
the
appropriate Analyzer, the assignment of Directory in ParallelReader
(or
ParallelWriter), etc.
karl wettin wrote on 07/08/2006 12:27 PM:
> On Sat, 2006-07-08 at 11:08 -0700, Chuck Williams wrote:
>
>> Karl, do you have specific reasons or use cases to normalize fields at
>> Document rather than at Index?
>>
>
> Nothing more than that the way the API looks it implies features that
>
On Sat, 2006-07-08 at 11:08 -0700, Chuck Williams wrote:
>
> Karl, do you have specific reasons or use cases to normalize fields at
> Document rather than at Index?
Nothing more than that the way the API looks it implies features that
does not exist. Boost, store, index and vectors. I've learned
Robert,
Thanks for your questions, things are beginning to fall into place
(see http://issues.apache.org/jira/browse/LUCENE-584):
On Saturday 08 July 2006 14:14, robert engels wrote:
> Is that really necessary for a filter? It seems that a filter implies
> efficiency over a "scoring", and that
[
http://issues.apache.org/jira/browse/LUCENE-562?page=comments#action_12419888 ]
Sam Hough commented on LUCENE-562:
--
Fair enough. An entry in the change log might be useful just incase somebody is
doing strange stuff like me. Many thanks.
> Allow Unstore
karl wettin wrote on 07/08/2006 10:27 AM:
> On Sat, 2006-07-08 at 09:46 -0700, Chuck Williams wrote:
>
>> Many things would be cleaner in Lucene if fields had a global semantics,
>>
>
>
>> Has this been considered before? Are there good reasons this path has
>> not been followed?
>>
On Sat, 2006-07-08 at 09:46 -0700, Chuck Williams wrote:
> Many things would be cleaner in Lucene if fields had a global semantics,
> Has this been considered before? Are there good reasons this path has
> not been followed?
I've been posting some advocacy about the current Field. Basically I
wo
On Jul 8, 2006, at 12:56 PM, Chuck Williams wrote:
I prefer to contribute to Lucene, but my workload simply
does not allow time to be spent on backporting.
I'll stand by my offer to do the backporting when it is possible and
does not do violence to the implementation.
I'd prefer to wait
Doug Cutting wrote on 07/08/2006 09:41 AM:
> Chuck Williams wrote:
>> I only work in 1.5 and use its features extensively. I don't think
>> about 1.4 at all, and so have no idea how heavily dependent the code in
>> question is on 1.5.
>>
>> Unfortunately, I won't be able to contribute anything sub
On Jul 8, 2006, at 12:41 PM, Doug Cutting wrote:
Since GCJ is effectively available on all platforms, we could say
that we will start accepting 1.5 features when a GCJ release
supports those features. Does that seem reasonable?
I have been doing a bit of reading on GCJ compatibility. I
Many things would be cleaner in Lucene if fields had a global semantics,
i.e., if properties like text vs. binary, Index, Store, TermVector, the
appropriate Analyzer, the assignment of Directory in ParallelReader (or
ParallelWriter), etc. were a function of just the field name and the
index. This
On Sat, 8 Jul 2006, Doug Cutting wrote:
Since GCJ is effectively available on all platforms, we could say that we
will start accepting 1.5 features when a GCJ release supports those features.
Does that seem reasonable?
+1
Andi..
-
Chuck Williams wrote:
I doubt any single contribution will change anyone's mind. I would like
to have clarity on the 1.5 decision before deciding whether or not to
contribute this and other things. My ParallelWriter contribution, which
also requires 1.5, is already sitting in jira.
Sitting in
Daniel John Debrunner wrote:
I'm new to Lucene but not Apache, this is not how Apache projects are
meant to work. All decisions must be on the mailing lists and decisions
are made by the community via "consensus gathering", not a sub-set of
folks off the list. Or am I reading too much into this c
DM Smith wrote:
> However, I think you have identified that the core people need to
> make a decision and the rest of us need to go with it. So, I suggest
> that Doug convene such a meeting of the minds and communicate the
> decision to the rest of us.
I'm new to Lucene but not Apache, thi
Attached is the incremental updating QueryFilter. The MyMultiReader
class is a basic extension of MultiReader that allows access to the
underlying IndexReaders.
Obviously this also requires that "reopen" be implemented so that
SegmentReaders for unchanged segments remain the same through th
Is that really necessary for a filter? It seems that a filter implies
efficiency over a "scoring", and that filters should be able to be
evaluated in a chained (or priority queue) fashion fairly efficiently
without any need for 'rewrites".
With the new incremental updates of a filter (based
On Saturday 08 July 2006 05:44, robert engels wrote:
> Agreed. The interface I proposed supports both sequential and random
> access to the filter - hiding the implementation.
For query searching, random access to a Filter is only needed
in the forward direction, e.g. by nextInclude(docNr) or sk
19 matches
Mail list logo
