qri-io / qri

you're invited to a data party!
https://qri.io
GNU General Public License v3.0
1.11k stars 66 forks source link

fix: deploy panics, double version removal, collection clean up #1871

Closed ramfox closed 3 years ago

ramfox commented 3 years ago

1) update to latest qfs to fix nil ctx bug 2) ensure we have a default source for deploy, this extends to the deferred Remove that gets triggered if something goes wrong with the deploy 3) adjust the deploy path to only attempt to remove the just saved version if we have an error while deploying after the dataset has saved. If the error occurs during the save, the Save path has its own clean up. Also, ensure we are only removing the previous version if this current deploy has saved a previous version. If there were no changes to save, don't erroneously remove a version. 4) Collection needs to be updated when a dataset creation fails. The collection catches the dataset creation information very early in the save process, so we need to also be updated if the creation fails, so that we can remove that dataset from the collection. We are now doing this using the ETDatasetCreateFail event

dustmop commented 3 years ago

An interesting discussion has happened around how to name, think of, and reuse events. To that end I tweaked some of the comments describing our dataset change events, but also wanted to lay out some general principles around event patterns.

The entire goal of using events is that they allow for looser coupling of subsystems. The publisher and listener shouldn't know too much about each other, all they know are event types and the associated payloads. Contrast this to a function call, wherein the caller knows explicitly what functionality it is invoking at a callsite. Events avoid this, at the loss of some clarity, but to the benefit of having less dependency on exactly how other code works and the manner in which it is implemented.

Event objects should only be as specific as they must be, from the perspective of the subsystem that is listening for them. Specifically, the listener doesn't need to all the details that caused an event to fire; as long as it can do the work needed to update its own state, it shouldn't need to concern itself with unnecessary details. This leads to a system with greater flexibility, better isolation of components, and better reuse of its parts.