lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Miller (Commented) (JIRA)" <>
Subject [jira] [Commented] (LUCENE-3622) separate IndexDocValues interface from implementation
Date Fri, 09 Dec 2011 17:03:39 GMT


Mark Miller commented on LUCENE-3622:

bq. we had some arguments when merging from the docvalues branch into trunk that the name
is easy to be confused with DocValues in the function package since they are both in core.
This is where my statement comes from.

Yeah, I got that. I wasn't involved in that discussion, but if I was, I would have argued
that calling it IndexDocValues didn't help the situation much and we should have just kept
it as DocValues anyway. I just don't think because a class moves to another lucene 'component'
that it helps the situation any. I still consider modules first class.

I'd also have argued that in 4 we should rename the function DocValues class to something
else. It's advanced to mess in that area, and people can handle a change in a move to 4.
> separate IndexDocValues interface from implementation
> -----------------------------------------------------
>                 Key: LUCENE-3622
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Task
>            Reporter: Robert Muir
>         Attachments: LUCENE-3622.patch
> Currently the o.a.l.index.values contains both the abstract apis and Lucene40's current
> I think we should move the implementation underneath Lucene40Codec, leaving only the
abstract apis.
> For example, simpletext might have a different implementation, and we might make a int8
> underneath preflexcodec to support norms.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message