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

Refactoring content object storage and update

    XMLWordPrintable

Details

    • Stetind Sprint 1, Stetind Sprint 2, Stetind Sprint 3, Stetind Sprint 4, Stetind Sprint 5, Stetind Sprint 6
    • 2

    Description

      Currently the storage and update of content preserves a big lack of the legacy kernel - that is redundant storage of fields in the dimensions language and version. Recall that the current kernel has a worst case of (n/2*l)+v*n fields where n is the amount of fields in the content type, l the amount of languages and v the amount of versions. Example worst case:
      99 non translatable attributes, one translatable attribute, 10 languages.
      Assuming to make for each translation one version - if the one translatable attribute is translated 10 times we have
      10 versions. So we have
      100 + 200 + 300 ... + 1000 = 5500 Fields. That are 5390 redundant fields.
      For each additional version we may get 999 more redundant fields.

      As this is one main reason for the lack of scalability storage engines may not want to do this in this way. But now they are kind of forced as
      the BL passes for each field definition values down - if set or not by the user. Note that the BL passes also copies from attributes which are not set by the user on update. And the current storage engine stores what it gets.

      Solution:
      The iteration over the field definitions must be done in the legacy storage engine and the BL only passes values which are set and does not make a fallback to the $fieldType->getEmptyValue on create and does not pass the old value on update (if not changed).

      The would enable other engines to avoid redundant storage.

      Note: Above the public API or in BL there still can be methods, which fill a content not containing all values with empty values if needed.

      Attachments

        Activity

          People

            Unassigned Unassigned
            christian.bacher-obsolete@ez.no Christian Bacher (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Time Tracking

                Estimated:
                Original Estimate - 1 day, 2 hours Original Estimate - 1 day, 2 hours
                1d 2h
                Remaining:
                Remaining Estimate - 0 minutes
                0m
                Logged:
                Time Spent - 1 week, 3 hours, 30 minutes
                1w 3h 30m