Eloquent Model Checkpoint

[imsafary]

Hey everyone,

I have a suggestion regarding Eloquent models, specifically concerning methods like getChanges, getOriginal, and isDirty. Often, we find ourselves sharing models between various classes, providers, and libraries. These components may modify the model object to fulfill their responsibilities, and at times, other classes might need access to the complete model information from a few steps back, which isn't necessarily the original state.

In light of this, I propose the introduction of a "checkpoint" feature for models. This feature can be implemented by developing a set of useful methods with names like:

$user->setCheckpoint("state1");: This method would create a snapshot of the current model, preserving its current attributes and information.

$userCheckpoint = $user->getCheckpoint("state1");: This method would retrieve specific model information at a given checkpoint. It's important to note that at the "state1" checkpoint, you can only access checkpoints that were registered up to the current state.

$user->applyCheckpoint("state1"): This method would take a given checkpoint and apply its information to the current state of the model. However, earlier and later checkpoints would still exist, allowing you to revert and restore the model as needed.

$user->getCheckpoints(): array;: This method would provide an array of all registered checkpoints for the model.

Implementing these checkpoint methods would enhance the flexibility and usability of Eloquent models, making it easier to manage state changes and retrieve specific model states when necessary.

[henzeb]

You mean like in transactions?

[Sophist-UK]

No - I don't think @imsafari / Mostafa is talking about transactions which provide atomicity (i.e. all or nothing) at a database level over several individual changes to database tables.

Instead (if I understand him correctly) he seems to be talking about creating a point-in-time "snapshot" of a specific instance of a model with an ability to revert that instance of the model to that point in time. This is a bit like taking a "deep copy" of the PHP object that is this model instance except that such a deep copy would be a hierarchy of new objects with new object references, and if there are references to the original objects elsewhere in other objects, then reverting to the previous state would imply replacing the contents of those objects in a way that these references were preserved. It should be noted that immutable objects would require entirely different handling.

What I am unclear about without undertaking a more detailed analysis is whether there would be gotcha situations where object references could go very wrong when reverting, and whether it might be simpler for the developer (who understands how objects are used elsewhere in the app) to do a shallow or deep or intermediate copy using bespoke code and then write bespoke code to recover.

I will say, however, this is edge case is IMO highly unlikely to ever be merged into the main code base, and would need to be written as a add-on package (e.g. where you add a trait to the model to get the additional functionality. Such a package would need to have comprehensive tests to ensure that reversion works as promised.

[henzeb]

I was talking about transaction savepoints. https://dev.mysql.com/doc/refman/8.0/en/savepoint.html

[Sophist-UK]

Ah - you learn something new every day. I guess that the concept is very similar, but (obviously) database SavePoints apply only to what has been sent to the DB but not yet committed, whereas model SavePoints would apply to models that may or may not have yet been sent to the DB.

[imsafary]

thanks for replies.

You mean like in transactions?

no, I'm not. its actually at run time and checkpoint (or snapshot or what ever we named) saves only on memory.

No - I don't think @imsafari / Mostafa is talking about transactions which provide atomicity (i.e. all or nothing) at a database level over ....

As previously mentioned, there are situations where we require a specific state of model data, often after making modifications or reverting to a previously checkpointed or snapshot state.
Additionally, when serializing an object model, it is possible to include checkpoints for storage on alternative memory drivers like Redis.
When we retrieve and unserialize an object from Redis, we also gain access to all associated checkpoints.
It's important to note that including checkpoints during serialization and unserialization is entirely optional.

Furthermore, as @Sophist-UK pointed out, we have the flexibility to create custom model types through third-party extensions or plugins. However, it's generally recommended to reserve these customizations for core concerns within Eloquent.

[Sophist-UK]

as @Sophist-UK pointed out, we have the flexibility to create custom model types through third-party extensions or plugins. However, it's generally recommended to reserve these customizations for core concerns within Eloquent.

You can try to see if Taylor will be interested in merging this if you write it, but my advice would be to write it as a package and then if it gains enough traction maybe Taylor will get interested in including it in base Laravel.

As for serialisation / unserialisation, perhaps my explanation about object references was a poor one, but nonetheless it is an important one if you are going to make the saving and reversion of checkpoints seamless for objects that hold references to parts of the model.