[
https://issues.apache.org/jira/browse/LUCENE-2793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13041560#comment-13041560
]
Simon Willnauer commented on LUCENE-2793:
-----------------------------------------
bq. Why not use a normal struct/bean like class here?
What I had in mind here is a more sophisticated IOContext. I'd like to see some
default IOCtx for Merge, Search, Write etc. that folks can simply modify if
needed. For that to work it should be immutable. The question here is if we go
the high level way like you suggested and make the most of the properties
private to the dir (like buffersize etc) or is we should make it available to
the user of the API. Some Dirs might have different defaults than others
though.
I can see why this should be private to the directory and it might make more
sense to simply indicate what the input / output is used for and let the
directory figure out the details. So yeah +1 to keep it high level. If bean or
copy-on-write builder I need to see what properties should be on it. so lets
keep that for later.
{quote}Ideally, I would also like to see details about the
merge/reader/writer "context", eg for merging I'd like to see the
OneMerge instance, for Reader/Writer maybe a SegmentInfo instance?
{quote}
I really don't like the idea of exploiting OneMerge to the Directory. We might
introduce some other internface that holds enough metadata to get the info and
let OneMerge implement this but we should not pass it down to the dir. Same is
true for SI I don't want directory mess around with those classes.
> Directory createOutput and openInput should take an IOContext
> -------------------------------------------------------------
>
> Key: LUCENE-2793
> URL: https://issues.apache.org/jira/browse/LUCENE-2793
> Project: Lucene - Java
> Issue Type: Improvement
> Components: core/store
> Reporter: Michael McCandless
> Assignee: Simon Willnauer
> Labels: gsoc2011, lucene-gsoc-11, mentor
> Attachments: LUCENE-2793.patch, LUCENE-2793.patch, LUCENE-2793.patch,
> LUCENE-2793.patch
>
>
> Today for merging we pass down a larger readBufferSize than for searching
> because we get better performance.
> I think we should generalize this to a class (IOContext), which would hold
> the buffer size, but then could hold other flags like DIRECT (bypass OS's
> buffer cache), SEQUENTIAL, etc.
> Then, we can make the DirectIOLinuxDirectory fully usable because we would
> only use DIRECT/SEQUENTIAL during merging.
> This will require fixing how IW pools readers, so that a reader opened for
> merging is not then used for searching, and vice/versa. Really, it's only
> all the open file handles that need to be different -- we could in theory
> share del docs, norms, etc, if that were somehow possible.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
