Solr
  1. Solr
  2. SOLR-2292

Lock down NamedList API, remove inefficent and esoteric methods

    Details

    • Type: Task Task
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 4.9, Trunk
    • Component/s: None
    • Labels:
      None

      Description

      Over in SOLR-2288, rmuir made some good points about locking down the NamedList API to protect people...

      I looked at your patch, and personally I think NamedList should really be type-safe.
      If users want to use it in a type-unsafe way, thats fine, but the container itself shouldn't be List<Object>.

      ...

      Separately, i just want to say the following about NamedList:

      All uses of this API should really be reviewed. I'm quite aware that it warns you about the fact that its slow for certain operations,
      but in my opinion these slow operations such as get(String, int) should be deprecated and removed.

      Any users that are using NamedList in this way, especially in loops, are very likely using the wrong datastructure.

      (emphasis added by me)

        Issue Links

          Activity

          Hide
          Robert Muir added a comment -

          Hossman: good idea to break out this issue. I found another trap that I think is actually even worse!

          NamedList documents this limitation (the linear search by key) in this way:

           * If access by key is more important, see {@link SimpleOrderedMap},
           * or simply use a regular {@link Map}
          

          So one might think SimpleOrderedMap wouldn't have these problems, especially from its documentation:

          <code>SimpleOrderedMap</code> is a {@link NamedList} where access by key is more
           * important than maintaining order when it comes to representing the
           * held data in other forms, as ResponseWriters normally do.
          

          Yet SimpleOrderedMap only extends NamedList!!! Its still a linear search!
          So we need to check uses of SimpleOrderedMap too, to look for n^2 bugs.

          Show
          Robert Muir added a comment - Hossman: good idea to break out this issue. I found another trap that I think is actually even worse! NamedList documents this limitation (the linear search by key) in this way: * If access by key is more important, see {@link SimpleOrderedMap}, * or simply use a regular {@link Map} So one might think SimpleOrderedMap wouldn't have these problems, especially from its documentation: <code>SimpleOrderedMap</code> is a {@link NamedList} where access by key is more * important than maintaining order when it comes to representing the * held data in other forms, as ResponseWriters normally do. Yet SimpleOrderedMap only extends NamedList!!! Its still a linear search! So we need to check uses of SimpleOrderedMap too, to look for n^2 bugs.
          Hide
          Mark Miller added a comment -

          No patches yet - any chance of this for a nearing 3.1?

          Show
          Mark Miller added a comment - No patches yet - any chance of this for a nearing 3.1?
          Hide
          Ryan McKinley added a comment -

          Yet SimpleOrderedMap only extends NamedList!!! Its still a linear search!

          FYI, the distinction between NamedList and SimpleOrderedMap is only in how they are written to json. In java API they are identical, but in json SimpleOrderedMap is

          {"foo":10,"bar":20}

          and NamedList shows ["foo",10,"bar",20]

          http://lucene.apache.org/solr/api/org/apache/solr/common/util/SimpleOrderedMap.html

          Show
          Ryan McKinley added a comment - Yet SimpleOrderedMap only extends NamedList!!! Its still a linear search! FYI, the distinction between NamedList and SimpleOrderedMap is only in how they are written to json. In java API they are identical, but in json SimpleOrderedMap is {"foo":10,"bar":20} and NamedList shows ["foo",10,"bar",20] http://lucene.apache.org/solr/api/org/apache/solr/common/util/SimpleOrderedMap.html
          Hide
          Robert Muir added a comment -
          Show
          Robert Muir added a comment - Moving out all unassigned issues set to 3.1 per this email: http://www.lucidimagination.com/search/document/f026cc56081b5a51/unassigned_jira_issues_set_for_3_1
          Hide
          Robert Muir added a comment -

          Bulk move 3.2 -> 3.3

          Show
          Robert Muir added a comment - Bulk move 3.2 -> 3.3
          Hide
          Robert Muir added a comment -

          3.4 -> 3.5

          Show
          Robert Muir added a comment - 3.4 -> 3.5
          Hide
          Hoss Man added a comment -

          Bulk of fixVersion=3.6 -> fixVersion=4.0 for issues that have no assignee and have not been updated recently.

          email notification suppressed to prevent mass-spam
          psuedo-unique token identifying these issues: hoss20120321nofix36

          Show
          Hoss Man added a comment - Bulk of fixVersion=3.6 -> fixVersion=4.0 for issues that have no assignee and have not been updated recently. email notification suppressed to prevent mass-spam psuedo-unique token identifying these issues: hoss20120321nofix36
          Hide
          Steve Rowe added a comment -

          Bulk move 4.4 issues to 4.5 and 5.0

          Show
          Steve Rowe added a comment - Bulk move 4.4 issues to 4.5 and 5.0
          Hide
          Uwe Schindler added a comment -

          Move issue to Solr 4.9.

          Show
          Uwe Schindler added a comment - Move issue to Solr 4.9.

            People

            • Assignee:
              Unassigned
              Reporter:
              Hoss Man
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:

                Development