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

Content search returns content several times when it has several locations

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: InputQ
    • Priority: High
    • Resolution: Unresolved
    • Affects Version/s: 1.10.0-beta3, 1.7.8, 1.13.4, 2.3.2, 2.4.0
    • Fix Version/s: None
    • Labels:
      None

      Description

      Currently only reproduced on Legacy Search engine, afaik not a problem with solr but someone should check.

      This was reproduced on a whim using Platform UI. Because REST API lookups adds latency, Platform UI uses Search for a lot of things to avoid that, including loading content by id's for sub items view. While that is something to solve at some point to be able to cache these lookups, thats beyond this issue.

      Both symptoms in UI, as well as the request and response payload attached as images.

      What happens is:

      • ContentQuery search using ContentIdCriterion is used, limit is set to same number previous location search result for sub items gave as it is below the current default max of 10 items
      • 5 Items are correctly returned as expected in this case
      • However the last item comes up twice because it has two locations (the other location is in media tree)

      Sp some join going wrong here in content search, or the criterion is using wrong table for content search here making it behave as a location criteria*.

      • As in we have had such issues in the past to, but they only affected location criteria, and solution to that was to deprecate them and introduce location search as the solution to it for correct modeling of the problem.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              Unassigned
              Reporter:
              andre.romcke@ez.no André Rømcke
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Dates

                Created:
                Updated:

                  Time Tracking

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