plank/laravel-checkpoint

A package for establishing a polymorphic many to many relationship between a model and a revisions table

laravel-checkpoint's Issues

Tagging/Statuses

From reviewing the documentation and quickly reviewing the code I can't tell if this allows publishing based on tags.

Use Case:

1. Create Model
2. Tag Model as "Draft" - Not visible via scope
3. Tag Model as "Published" - Now visible (call it V1)
4. Update Model (V1) - Saved as new checkpoint (v2) Tag as "Draft"
5. V1 should still be visible. - Status Published
6. V2 should not be visible - Status Draft
7. Tag V2 Model as "Published"
8. V1 is no longer visible as the date stamp is older than V2, but is still accessible if looking for point-in-time
9. V2 is now visible by default

Does this make sense, and is this possible with this package?

Limit Smallest Viewable Changeset to Checkpoint

Currently we are supporting the ability to view the database at any point in time, which has a few side effects:

1. 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.

2. Long CRUD operation times when many cascading revisions need to be created
3. 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.

cant install with new laravel installation

Problem 1
- Root composer.json requires plank/laravel-checkpoint ^2.1 -> satisfiable by plank/laravel-checkpoint[v2.1.0].
- plank/laravel-checkpoint v2.1.0 requires illuminate/support 5.8.*|^6.0|^7.0|^8.0|^9.0 -> found illuminate/support[v5.8.0, ..., v5.8.36, v6.0.0, ..., v6.20.44, v7.0.0, ..., v7.30.6, v8.0.0, ..., v8.83.27, v9.0.0, ..., v9.52.7] but these were not loaded, likely because it conflicts with another require.

You can also try re-running composer require with an explicit version constraint, e.g. "composer require plank/laravel-checkpoint:*" to figure out if any version is installable, or "composer require plank/laravel-checkpoint:^2.1" if you know which you need.

Implement HasRevision Utility Functions

Overview

There are a number of stub functions that need to be implemented in the HasRevisions trait. Currently they are some stubs that can be elaborated on.

Details

The functions that are stubbed are as follows: rollbackToRevision, revertToRevision, deleteAllRevisions with some comments but more specifically.

• rollbackToRevision: Should iterate through all the revisions between the passed revision and current, and delete them all. This will effectively rollback to the given revision

• revertToRevision: Should save the given model as a revision to effectively restore that model as the new current revision of that instance while maintaining the revision history before it.

• deleteAllRevisions: Delete all the revisions for a given model. effectively acting as a force delete - potentially rename?

Additionally, and probably most importantly we should add a insertRevisionAfter

• insertRevisionAfter: allow for a new revision of an object to be placed into the lineage of a model instance. Ie; given an new revision place it after a chosen revision