Uploaded image for project: 'eZ Publish / Platform'
  1. eZ Publish / Platform
  2. EZP-22859

Object Relations versions not saved correctly in Solr

    Details

      Description

      Steps to reproduce:

      1. Using a clean, fully patched installation of eZ Publish 5.2/eZ Find 5.2, create a new class with the following attributes:

      	Title [Text line], required, searchable
      	Related content [Object relations], not required, searchable
      

      2. Create an object (e.g. 12306_1) of that class, and use the "Object relations" attribute to relate to another object of the same class (e.g. 12306_2);
      3. On the Solr admin interface - accessible on http://localhost:8983/solr/url by default - search for "12306". There should be two results, one for "12306_1" and one for "12306_2";
      4. The XML structure for "12306_1" contains a "submeta_related_content" section:

      ...
      <arr name="submeta_related_content___current_version_si">
        <int>1</int>
      </arr>
      ...
      

      ...where current_version is 1, which is correct.

      5. Create a new version of "12306_2";
      6. Delete version 1 of "12306_2";
      7. Re-index Solr;
      8. On the Solr admin interface, search again for "12306". The resulting XML structure for "12306_1" no longer has a "submeta_related_content" section, which is wrong, since "12306_2" is still related to "12306_1".

        Issue Links

          Activity

          Show
          Yannick Roger (Inactive) added a comment - https://github.com/ezsystems/ezfind/pull/163
          Show
          Yannick Roger (Inactive) added a comment - Fixed in master: https://github.com/ezsystems/ezfind/commit/4ed347babf77672e9239420bab77630a317a2c3d
          Hide
          Pedro Resende (Inactive) added a comment -

          Tested and approved by Q.A.

          Show
          Pedro Resende (Inactive) added a comment - Tested and approved by Q.A.
          Hide
          Bruno Fassino added a comment -

          This did not fully fixed the problem for us, because the problem affects not only the submeta attributes.
          In ezfsolrdocumentfieldobjectrelation.php slighly after the patched part, there is a $this->getPlainTextRepresentation() which calls the metaData function of eZContentObjectAttribute.
          Now in kernel/classes/datatypes/ezobjectrelationlist/ezobjectrelationlisttype.php the metaData function has the same "undesired" behavior: it uses the version number stored in the relation list attribute.
          Only after having modified that metaData() to use the current version, all the solr attributes related to the relation list worked properly in case of editing of objects mentioned in the relation list itself.

          Show
          Bruno Fassino added a comment - This did not fully fixed the problem for us, because the problem affects not only the submeta attributes. In ezfsolrdocumentfieldobjectrelation.php slighly after the patched part, there is a $this->getPlainTextRepresentation() which calls the metaData function of eZContentObjectAttribute. Now in kernel/classes/datatypes/ezobjectrelationlist/ezobjectrelationlisttype.php the metaData function has the same "undesired" behavior: it uses the version number stored in the relation list attribute. Only after having modified that metaData() to use the current version, all the solr attributes related to the relation list worked properly in case of editing of objects mentioned in the relation list itself.
          Hide
          Yannick Roger (Inactive) added a comment -

          Bruno, you should create a new issue and even a pull request with your proposed fix so it can be reviewed by our engineering team.

          Show
          Yannick Roger (Inactive) added a comment - Bruno, you should create a new issue and even a pull request with your proposed fix so it can be reviewed by our engineering team.

            People

            • Assignee:
              Unassigned
              Reporter:
              Nuno Oliveira (Inactive)
            • Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Remaining Estimate - 0 minutes
                0m
                Logged:
                Time Spent - 6 hours
                6h