Solr
  1. Solr
  2. SOLR-3743

stored copyField targets, optimistic concurrency, atomic updates

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.0
    • Component/s: None
    • Labels:
      None

      Description

      Stored copyField targets do not work well with other solr features.
      Consider the following getting started guide:
      http://yonik.com/solr/getting-started/

      After the document update, a get of the resulting document reveals:

      /opt/code/lusolr/solr$ curl http://localhost:8983/solr/get?id=book1
      {
        "doc":
        {
          "id":"book1",
          "title":["American Gods"],
          "author":"Neil Gaiman",
          "author_s":["Neil Gaiman",
            "Neil Gaiman"],
          "cat":["fantasy"],
          "pubyear_i":2001,
          "ISBN_s":"0-380-97365-0",
          "_version_":1410692581016207360}}
      

      note the double author_s.

      A user using realtime-get and optimistic concurrency may run across the same issue. The other field stored field that is a copyField target is price_c.

      1. SOLR-3743.patch
        5 kB
        Yonik Seeley
      2. SOLR-3743.patch
        3 kB
        Yonik Seeley

        Issue Links

          Activity

          Hide
          Yonik Seeley added a comment -

          I tried to create a test case, but for some reason it doesn't seem to have the same behavior as the example above...

          Show
          Yonik Seeley added a comment - I tried to create a test case, but for some reason it doesn't seem to have the same behavior as the example above...
          Show
          Jun Ohtani added a comment - maybe related issues, https://issues.apache.org/jira/browse/SOLR-3502 and https://issues.apache.org/jira/browse/SOLR-3657
          Hide
          Yonik Seeley added a comment -

          I tried to create a test case, but for some reason it doesn't seem to have the same behavior as the example above...

          Ah, OK - if real-time get retrieves the fields from the tlog, copyfields will not have been run yet.
          It seems like we should prevent real-time get from returning copyfield targets when retrieved from the index.

          Show
          Yonik Seeley added a comment - I tried to create a test case, but for some reason it doesn't seem to have the same behavior as the example above... Ah, OK - if real-time get retrieves the fields from the tlog, copyfields will not have been run yet. It seems like we should prevent real-time get from returning copyfield targets when retrieved from the index.
          Hide
          Yonik Seeley added a comment -

          Here's a patch that seems to fix things by not returning copyField targets in real-time get.

          Show
          Yonik Seeley added a comment - Here's a patch that seems to fix things by not returning copyField targets in real-time get.
          Hide
          Yonik Seeley added a comment -

          committed.

          We should also consider changing author_s to author_facet (i.e. an indexed-only dynamic string field).

          Show
          Yonik Seeley added a comment - committed. We should also consider changing author_s to author_facet (i.e. an indexed-only dynamic string field).
          Hide
          Dana Cohen added a comment -

          this is still an issue for me. i can reproduce the same as above without explicitly using real-time get or solr cloud.
          this may need to be reopened?

          curl 'http://localhost:8983/solr/update?commit=true' -H 'Content-type:application/json' -d '[{"id":"transcript_071012.pdf","mdate":{"set":"2012-07-10T23:59:59Z"}}]'

          Show
          Dana Cohen added a comment - this is still an issue for me. i can reproduce the same as above without explicitly using real-time get or solr cloud. this may need to be reopened? curl 'http://localhost:8983/solr/update?commit=true' -H 'Content-type:application/json' -d ' [{"id":"transcript_071012.pdf","mdate":{"set":"2012-07-10T23:59:59Z"}}] '
          Hide
          Uwe Schindler added a comment -

          Closed after release.

          Show
          Uwe Schindler added a comment - Closed after release.

            People

            • Assignee:
              Unassigned
              Reporter:
              Yonik Seeley
            • Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development