Class: Eco::API::UseCases::GraphQL::Helpers::Location::Command::Diffs

Inherits:

Data::Locations::NodeDiff::NodesDiff

• Object
• Data::Hashes::ArrayDiff
• Data::Locations::NodeDiff::NodesDiff
• Eco::API::UseCases::GraphQL::Helpers::Location::Command::Diffs

Includes:

Stages::Commandable

Defined in:

lib/eco/api/usecases/graphql/helpers/location/command/diffs/stages.rb,
lib/eco/api/usecases/graphql/helpers/location/command/diffs.rb,
lib/eco/api/usecases/graphql/helpers/location/command/diffs/stages/sortable.rb,
lib/eco/api/usecases/graphql/helpers/location/command/diffs/stages/commandable.rb,
lib/eco/api/usecases/graphql/helpers/location/command/diffs/stages/diff_sortable.rb,
lib/eco/api/usecases/graphql/helpers/location/command/diffs/stages/diff_sortable/for_archive.rb,
lib/eco/api/usecases/graphql/helpers/location/command/diffs/stages/diff_sortable/for_unarchive.rb,
lib/eco/api/usecases/graphql/helpers/location/command/diffs/stages/sortable/relation_safe_sort.rb

Overview

Note:

The order in which updates should happen: (1) UNARCHIVE (top-bottom) should go FIRST, to ensure consistency througout all the stages sequence

• Currently: CANNOT UPDATE (or move) ARCHIVED NODES
• It can unarchive children with same archivedToken
  • Changing order to happen after MOVE does NOT prevent this to happen.
  • And archived children nodes cannot be moved somewhere else anyway either.
• Within UNARCHIVE, the preferable order would be ALL nodes from leafs to root
  • to the purpose of preventing already unarchived node errors
  • because, from top to bottom, the unarchivedToken could have already unarchived children.
  • This still does not prevent the unintended consequence of automatic unarchive of children.
• HOWEVER, the error you can't unarchive a child of an archived node suggest that within UNARCHIVE, the order MUST BE from top-to-bottom, and MOREOVER
  • Among nodes with the same archiveToken only the topest one should be unarchived (the others follow), which prevents the errors already unarchived node and can't unarchive child of archived node
  • Children with same archiveToken that are not to be unarchived, should be rearchived
  • IMPORTANT: this could require to track all the way up to the first archived ancestor, path from leave-to archive-root, and then for unarchive from top to bottom only those with different archiveToken. (1.b) IMPORTANT: automatically unarchived nodes (archivedToken) that should remain archived should be RE-ARCHIVEd as part of the update (in the ARCHIVE stage) (2) UPDATE ID (--) needs to happen before
• This allows other commands to refer to nodes and their parents with current ids.
• If INSERT happened before UPDATE ID, they would need to refer to the previous value of parentId, but inserts don't have previous source in NodeDiff (they are new) and only a working-around (i.e. general lookup) would allow to obtain this value (not really neat)
• Technically, the internal ORDER does NOT MATTER, but if something has to fail, let's make it fail big: so let's do top-to-bottom. (2.b) UPDATE NAME can happen anywhere, so let's keep tree consistent and do it as soon as possible. (3) INSERT (top-bottom) has priority over MOVE, as there may be existing nodes being moved to or inserted to.
• And should happen AFTER the UNARCHIVE, because we could be inserting to an unarchived node and that would make our inserted node an archived one as well.
• The internal ORDER MATTERS and it's from top to bottom (root to leaves) to prevent unknown parentId error. (4) MOVE (--) should happen before ARCHIVE and after UNARCHIVE
• This prevents active nodes to be archived from their previous parent node, now being archived.
• It also prevents the error of moving to an archived node, or not being able to move an archived node.
• If it happened before UNARCHIVE, we would be either move ARCHIVED nodes to be unarchived, or moving other nodes to them before they are unarchived
• Technically, for MOVE, the internal ORDER does NOT MATTER. It would matter for new/inserted nodes, but we do not move inserted nodes (we add them directly to the parent).
  • However, to build the remap tags table, it does matter: from bottom to top. Children should be retagged first because retagging first parents changes the path of their children retags. (5) ARCHIVE (bottom-top) should happen always LAST, after nodes have been MOVED. • The order of archiving should probably be: (a) although firstly thought go from leafs to root to prevent the archiveToken it should go from top-to-bottom, so precisely the archiveToken is generated and history well sorted. (b) to preventing already archived node errors, we should only include the parent (6) RE-ARCHIVE (bottom-top) see (1.b) all those that were automatically unarchived but should remain archived. • The neat solution is to recalculate changes with the live_tree and the final desired result, but perhaps only target those to be re-archived?

Defined Under Namespace

Modules: Stages

Constant Summary

Constants inherited from Data::Locations::NodeDiff::NodesDiff

Data::Locations::NodeDiff::NodesDiff::SELECTORS

Constants included from Language::Models::ClassHelpers

Language::Models::ClassHelpers::NOT_USED

Instance Attribute Summary

Attributes inherited from Data::Locations::NodeDiff::NodesDiff

#original_tree

Attributes inherited from Data::Hashes::ArrayDiff

#source_1, #source_2, #src_h_1, #src_h_2

Attributes included from Language::AuxiliarLogger

#logger

Instance Method Summary

• #commands ⇒ Object

Methods included from Stages::Commandable

#stage_commands

Methods inherited from Data::Locations::NodeDiff::NodesDiff

#diffs, #diffs_details, #diffs_summary, #initialize, #unarchive, #unarchive_src

Methods included from Data::Locations::NodeDiff::NodesDiff::Selectors

#selector

Methods inherited from Data::Hashes::ArrayDiff

#diffs, #diffs?, #initialize, #source_results

Methods included from Language::Models::ClassHelpers

#class_resolver, #inheritable_attrs, #inheritable_class_vars, #inherited, #instance_variable_name, #new_class, #redef_without_warning, #resolve_class, #to_constant, #used_param?

Methods included from Language::AuxiliarLogger

#log

Constructor Details

This class inherits a constructor from Eco::Data::Locations::NodeDiff::NodesDiff

Instance Method Details

#commands ⇒ Object

# File 'lib/eco/api/usecases/graphql/helpers/location/command/diffs.rb', line 12

def commands
  self.class.stages.each_with_object([]) do |stage, out|
    comms = stage_commands(stage)
    out.concat(comms)
    yield(comms, stage) if block_given?
  end
end