You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently we are supporting the ability to view the database at any point in time, which has a few side effects:
Model events do not behave totally intuitively
Creating/Created + Saving/Saved get fired several times during a single updated for example
The context which relates a model between between ing events and ed events is lost during revisioning process.
Long CRUD operation times when many cascading revisions need to be created
Consuming applications and other packages will likely need to account for checkpoint's presence
To address only point (1) from above, we can add a helper/service in the container which would provide revisioning context on a given model.
The longer term solution would be to remove the revisioning process from occurring during the model event lifecycle, and instead perform all revisioning when creating a new checkpoint. The key benefit of this, is that checkpoint does not inject itself into the normal Laravel model event lifecycle.
A further consideration would be to duplicate revisioned tables when creating new checkpoints instead of storing revision information on the revisions table. This would have the key benefit of making existing unique constraints behave correctly as well as keeping the table size low.
The text was updated successfully, but these errors were encountered:
Currently we are supporting the ability to view the database at any point in time, which has a few side effects:
ing
events anded
events is lost during revisioning process.To address only point (1) from above, we can add a helper/service in the container which would provide revisioning context on a given model.
The longer term solution would be to remove the revisioning process from occurring during the model event lifecycle, and instead perform all revisioning when creating a new checkpoint. The key benefit of this, is that checkpoint does not inject itself into the normal Laravel model event lifecycle.
A further consideration would be to duplicate revisioned tables when creating new checkpoints instead of storing revision information on the
revisions
table. This would have the key benefit of making existing unique constraints behave correctly as well as keeping the table size low.The text was updated successfully, but these errors were encountered: