Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
It would be amazing if Replication provided base classes for replicators to fire events before, during, and after a replication. Because replications are potentially heavily stateful, I think this use the Symfony event dispatcher system. At the very least, there should be pre- and post-replication events, and a single class to store the source and target workspaces, plus the current status of the replication.
Comment | File | Size | Author |
---|---|---|---|
#2 | 2814055-2.patch | 3.04 KB | phenaproxima |
Comments
Comment #2
phenaproximaHere's a patch that implements the things I described in the IS.
Comment #3
josephdpurcell CreditAttribution: josephdpurcell at Digital Bridge Solutions commentedThis looks good! Do you think a ReplicationEvent subscriber would want to know if any filters were used or what filter parameters were sent?
For this reason, I think the ReplicationTask should be added as well. Also consider that if we were more closely following the CouchDB pattern the ReplicationTask would even include the source and target Workspaces, so the task object should be considered as important as the source/target workspace.
Comment #4
timmillwoodEven though this event has not been committed to Replication module it's already being fired in Workspace module in
\Drupal\workspace\ReplicatorManager::doReplication
.I'm wondering if this is the best place to fire the event.
At the end of a replication a ReplicationLog entity should be created / updated, I wonder if this would be a better place to fire the event?
Comment #5
timmillwood@phenaproxima - Do you still have a need for this?
If not, maybe we can close and remove all the related code from Workspace module.
Comment #6
phenaproximaI do not, as Lightning will not support preview/workspace functionality until it's in core :) Let's close this.
Comment #7
timmillwoodWe've got to the position where we need events, therefore I'm going to commit this "as is" then open a follow up if we need to iterate.
Comment #9
timmillwoodComment #11
timmillwoodI've actually decided to revert this because I think the event should handle workspace pointers, which aren't added until the workspace module. So will move it there with #2971926: Better dispatch events.