Uploaded image for project: 'Hippo CMS'
  1. Hippo CMS
  2. CMS-12770

AutoExportConfigExporter is expected to process from a parent of changed paths

    XMLWordPrintable

Details

    • Bug
    • Status: Open
    • Normal
    • Resolution: Unresolved
    • None
    • None
    • repository
    • None
    • Pulsar
    • !Pulsar - Misc brXM

    Description

      The way the AutoExportConfigExporter is used and seeded with "changed" paths to process requires it to use awkward logic to make sure it 'does the right thing', which for example bug REPO-2294 surfaced as being brittle.

      Currently the AutoExportConfigExporter is invoked from the EventJournalProcessor feeding it with the parent path(s) of the actual detected changed paths (add, modify, delete).
      Which was done (then) because for at least a deleted path that node no longer exists, thus the AutoExportConfigExporter must (somehow) take the parent node/path into account anyhow, and the same is needed for changed properties for which it parent path is the node path. 

      To simplify that 'changed paths seeding' and generalized processing in AutoExportConfigExporter therefore always the parent path is seeded to be processed, for config (node) paths. 

      But this solution makes it both less efficient and brittle because:

      • too many nodes (all the children, including the siblings of the actual changed path) needs to processed
      • when config and content category nodes are sibling (or forced to be sibling by using a overrideresidualchildnodecategory) under such parent node the logic becomes flawed (REPO-2294) and the AutoExportConfigExporter may export 'too much' (or maybe even 'too little') 

      These problems of the current implementation was already (somewhat) recognized in the beginning, and there are specific TODO comments in the code for that.

      The REPO-2294 issue has been fixed on a different level, for now, dealing with the incorrect intermediate outcome of the AutoExportConfigExporter downstream in the DefinitionMergeService.

      But the underlying root cause, and the functional behavior/expectancy of the AutoExportConfigExporter output, based on which input, still very much is open.

      For other/new usages of the AutoExportConfigExporter (besides the current 'event journal driven 'changes') this may need to be revisited and get fixed at the actual root cause level.

      Attachments

        Issue Links

          Activity

            People

              pulsarteam Pulsar Team
              adouma Ate Douma
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

                Created:
                Updated: