I also need the ability to achieve rapid updates. ParallelReader is
attractive because my content naturally segments into a set of large and
small stored fields where the small fields need to be accessed quickly,
plus stable and mutable indexed fields where the mutable fields need to
be updated qu
On Friday 16 December 2005 11:42, Erik Hatcher wrote:
> In my latest project, I've written code to walk a general Query and
> do three different manipulations of it: 1) Convert it to a SpanQuery
> 2) Change a specified field to another field for each nested Query 3)
> Rotate (Span)RegexQuery
I will look into it.
Thanks for the suggestion,
Nicolas
Le 12:25 2005-12-16, vous avez écrit:
Nicolas Belisle wrote:
Since Java Content Repository uses java.io.InputStream, I extended
RAMInputStream to achieve random reads from the java.io.InputStream.
(Have a better idea ?)
So you're buf
Nicolas Belisle wrote:
Since Java Content Repository uses java.io.InputStream, I extended
RAMInputStream to achieve random reads from the java.io.InputStream.
(Have a better idea ?)
So you're buffering the entire file? That doesn't sound good. If there
are no provisions for random access, t
Personally, I tend to use DOM for config type stuff where performance
doesn't matter. I tend to avoid it for per-request XML processing
when you want potentially thousands per second. Besides being slower,
it generates more garbage.
-Yonik
On 12/16/05, Erik Hatcher <[EMAIL PROTECTED]> wrote:
>
Lukas,
don't worry - we hear you and can see your patch. I will have a look at
it the next days. Please keep in mind that all committers are volunteers
and spend their rare free time in improving lucene.
Bernhard
Lukas Zapletal wrote:
Dne Sun, 11 Dec 2005 17:51:08 +0100 (CET)
"Lukas Zaplet
In my latest project, I've written code to walk a general Query and
do three different manipulations of it: 1) Convert it to a SpanQuery
2) Change a specified field to another field for each nested Query 3)
Rotate (Span)RegexQuery terms.
I have a lot of duplication of this recursive Query p
Dne Sun, 11 Dec 2005 17:51:08 +0100 (CET)
"Lukas Zapletal (JIRA)" <[EMAIL PROTECTED]> napsal(a):
> I have done what you requested (sorry for the late delay - too busy). I also
> found a bug in RAMOutputStream - the implementation of flushBuffer method was
> not able to write any buffers longer t
I don't think DOM and RAM is necessarily an issue.
The object construction process accesses the content
in the same order that a SAX based path takes so that
just seems an appropriate approach. There is no need
to leap around the structure in any other way from
what I can see, which is where DOM w
Why wouldn't simply using DOM be sufficient? Is it envisioned that
a query XML would be large enough to prohibit RAM DOM loading of the
entire document?
Erik
On Dec 16, 2005, at 2:51 AM, mark harwood wrote:
While SAX is fast, I've found callback interfaces
more difficult to
deal
Nicolas - I'm going to defer comments on this to others more intimate
with these internals. If you have a compelling reason to open up
some package privates, then that wouldn't be a problem. We've done
this several times before.
Erik
On Dec 14, 2005, at 12:52 PM, Nicolas Belisle
11 matches
Mail list logo
