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

Specify a api to field types for dealing with relation handling

    Details

    • Epic Link:
    • Sprint:
      Stetind Sprint 1, Stetind Sprint 2, Stetind Sprint 3, Stetind Sprint 4, Stetind Sprint 5, Stetind Sprint 6

      Description

      Based on the code produced in #EZP-20034 find a way to create a low level interface to be able to reuse code across fieltypes for relations.

      ...

      Some background:

      All relations are stored using ezcontentobject_link table, with some specifics.

      Object level relations

      In legacy storage object level relations from one content object to a same other content object are merged into single DB row, using ezcontentobject_link.relation_type as a bitmask.

      There are three types of relations on object level: common, XML link and XML embed. Common type relations are created manually, while XML link and XML embed type relations are created automatically whenever an internal link or embed tag is created inside XML text field of a content object. For this reason object level relations are not added and removed directly, but through adding rows into ezcontentobject_link table with special op codes, which are processed when content is published.

      Attribute level relations

      There is only one type of attribute level relations: (obviously) attribute type relations. Thus attribute type relations are never merged using bitmask, also they are manipulated direcly (op codes are not used).

        Issue Links

          Activity

          Hide
          André Rømcke added a comment -

          Possible approach:

          • create the "addRelations()" api to field types, this should add the relation on the version (or ignore if already there)
          • legacy SE should merge these entries during publishing, just like legacy kernel does
          Show
          André Rømcke added a comment - Possible approach: create the "addRelations()" api to field types, this should add the relation on the version (or ignore if already there) legacy SE should merge these entries during publishing, just like legacy kernel does
          Hide
          Petar Spanja (Inactive) added a comment - - edited

          After some research:

          In difference to amended description, op code usage in Legacy Stack is in fact extraneous.
          Legacy Stack always has relations in consistent state, which is achieved by having link and embed type relations data available in eZContentObject::$InputRelationList property (used by eZContentObject::commitInputRelations() method).

          This is helpful for handling relations within Legacy Storage, where op codes have to be used since no similar mechanism exists (and is not desired).

          So prior to implementing op codes for handling object level relations in Legacy Storage, and in order to avoid conflicts, extraneous handling of op codes in Legacy Stack has to be removed.

          See: https://jira.ez.no/browse/EZP-20239

          Show
          Petar Spanja (Inactive) added a comment - - edited After some research: In difference to amended description, op code usage in Legacy Stack is in fact extraneous. Legacy Stack always has relations in consistent state, which is achieved by having link and embed type relations data available in eZContentObject::$InputRelationList property (used by eZContentObject::commitInputRelations() method). This is helpful for handling relations within Legacy Storage, where op codes have to be used since no similar mechanism exists (and is not desired). So prior to implementing op codes for handling object level relations in Legacy Storage, and in order to avoid conflicts, extraneous handling of op codes in Legacy Stack has to be removed. See: https://jira.ez.no/browse/EZP-20239
          Hide
          André Rømcke added a comment - - edited
          Show
          André Rømcke added a comment - - edited Pull request for review: https://github.com/ezsystems/ezpublish-kernel/pull/201
          Show
          André Rømcke added a comment - Merged in https://github.com/ezsystems/ezpublish-kernel/commit/bdbe486e48a03555f514c463d79c01759d0d9aa8
          Hide
          Gaetano Giunta (Inactive) added a comment -

          Might as well deprecate usage of direct relationships without an attribute (make it availabel only if a setting is enabeld).
          This as part of the cleanup-bad-features effort

          Show
          Gaetano Giunta (Inactive) added a comment - Might as well deprecate usage of direct relationships without an attribute (make it availabel only if a setting is enabeld). This as part of the cleanup-bad-features effort
          Hide
          Marcos Loureiro (Inactive) added a comment -

          QA Approved

          Show
          Marcos Loureiro (Inactive) added a comment - QA Approved

            People

            • Assignee:
              Unassigned
              Reporter:
              André Rømcke
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - 2 days Original Estimate - 2 days
                2d
                Remaining:
                Remaining Estimate - 0 minutes
                0m
                Logged:
                Time Spent - 1 week, 2 days, 4 hours, 55 minutes
                1w 2d 4h 55m

                  Agile