[
https://issues.apache.org/jira/browse/LUCENE-3760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13208382#comment-13208382
]
Robert Muir commented on LUCENE-3760:
-------------------------------------
{quote}
You mean if IndexReader.getCommitUserData() is faster than
IndexReader.open().getIndexCommit().getUserData()? Do I really need to
benchmark this !?
{quote}
Nope, but thats not really the question. I mean in the full picture of the
application, is there another way?
{quote}
The static method just reads the SegmentInfos and returns the commitData.
Opening an IndexReader at least opens its all sub-segments, loads norms,
deleted docs and what not.
{quote}
wait, i dont think thats totally true. Opening the static method may or may not
also read in fieldinfos (as they are tied to segmentinfos in trunk currently).
Opening an indexreader doesnt load norms until you ask for them, for example.
{quote}
Look, it's not like I'm trying to add a new API. It existed for a long time,
and it happens to be that I'm using it (and maybe others who didn't speak up).
So why deprecate it?
{quote}
Well I thought the API was confusing, especially the overloaded names, but when
looking into it, I started to question why it needs to exist.
I think this is ok: we can't keep adding and adding, I think its good to try to
hide some of this stuff.
Especially in Lucene's trunk: lots of things in o.a.l.index (SegmentInfos,
public ctors to SegmentReader, etc) don't really need to be public anymore IMO,
some of this was expert workarounds for the fact we didn't have an extensible
codecs package. We shouldn't try to support 2 "apis" from this perspective,
accessing parts of the index through expert methods and at the same time having
a codec api.
{quote}
I'm also using it in the SearcherTaxoManager (not yet uploaded to LUCENE-3786)
to inspect the commit data on the taxonomy directory before I create a new
DirTaxoReader, which is very expensive. So why nuke it?
{quote}
Well its still available in 3.x as deprecated methods... were you planning on
making a patch against 3.x for LUCENE-3786 initially?
here's an idea: how about we defer this discussion until we see your patch? If
it makes sense for LUCENE-3786, then we have a valid use case?
> Cleanup DR.getCurrentVersion/DR.getUserData/DR.getIndexCommit().getUserData()
> -----------------------------------------------------------------------------
>
> Key: LUCENE-3760
> URL: https://issues.apache.org/jira/browse/LUCENE-3760
> Project: Lucene - Java
> Issue Type: Improvement
> Reporter: Michael McCandless
> Assignee: Michael McCandless
> Fix For: 3.6, 4.0
>
> Attachments: LUCENE-3760.patch, LUCENE-3760.patch
>
>
> Spinoff from Ryan's dev thread "DR.getCommitUserData() vs
> DR.getIndexCommit().getUserData()"... these methods are confusing/dups right
> now.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
