Details

      Description

      Regression introduced in https://jira.ez.no/browse/EZP-21411 has been detected.

      steps to reproduce:
      • (in an environment with eZOracle and the patch from EZP-21411 applied)
      • Create and publish an object with a ezenum field
      • Verify that the value set to the ezenum field is not stored

        Issue Links

          Activity

          Hide
          Pedro Resende (Inactive) added a comment -

          Tested and approved by Q.A. on eZ Publish 4.7 and 5.0, since the versions after aren't certified to use eZ Oracle

          Show
          Pedro Resende (Inactive) added a comment - Tested and approved by Q.A. on eZ Publish 4.7 and 5.0, since the versions after aren't certified to use eZ Oracle
          Hide
          Bertrand Dunogier added a comment - - edited

          Merged to ezsystems/ezpublish-legacy/master @65eaea (revert) & @fcad1339.

          Show
          Bertrand Dunogier added a comment - - edited Merged to ezsystems/ezpublish-legacy/master @65eaea (revert) & @fcad1339 .
          Hide
          Bertrand Dunogier added a comment - - edited

          I have thoroughly studied this part of the code, and came to the conclusion that the whole short name thing is broken on oracle. I don't see how it could not be.

          See https://github.com/ezsystems/ezpublish-legacy-ee/blob/stable-4.7/kernel/classes/ezpersistentobject.php#L79. This is where a row provided to initialize a persistent object is checked for short_name. The short name is a shortened name for a field, a workaround that "fixes" limited size of field names in certain RDBMS (oracle, postgresql...).

          The loop checks if there is a short_name for the PO's attribute. If there is, it uses the short_name to read from the provided $row. This implies that we should use the short name, not the normal one, as the key when initializing a persistent object. We don't. Not for eZEnumObjectValue, nor for eZURLObjectLink (the only 2 persistent objects that use this feature).

          On the other hand, I guess that the logic in setAttribute isn't flawed, which explains why the customer's patch works.

          Show
          Bertrand Dunogier added a comment - - edited I have thoroughly studied this part of the code, and came to the conclusion that the whole short name thing is broken on oracle. I don't see how it could not be. See https://github.com/ezsystems/ezpublish-legacy-ee/blob/stable-4.7/kernel/classes/ezpersistentobject.php#L79 . This is where a row provided to initialize a persistent object is checked for short_name . The short name is a shortened name for a field, a workaround that "fixes" limited size of field names in certain RDBMS (oracle, postgresql...). The loop checks if there is a short_name for the PO's attribute. If there is, it uses the short_name to read from the provided $row . This implies that we should use the short name, not the normal one, as the key when initializing a persistent object. We don't. Not for eZEnumObjectValue , nor for eZURLObjectLink (the only 2 persistent objects that use this feature). On the other hand, I guess that the logic in setAttribute isn't flawed, which explains why the customer's patch works.
          Hide
          Bertrand Dunogier added a comment -

          Reproduced.

          Show
          Bertrand Dunogier added a comment - Reproduced.

            People

            • Assignee:
              Unassigned
              Reporter:
              Joaquim Cavalleri (Inactive)
            • Votes:
              1 Vote for this issue
              Watchers:
              5 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 - 1 day, 6 hours, 36 minutes
                1d 6h 36m