I have been working on a project that utilizes multiple database connections and I want versioning within all of the databases.

I published the migrations and updated them to create the version tables within each of the databases. This worked perfectly, however, when saving or deleting a records from a versionable table it only puts records into the default database which is not the desired outcome.

It would be useful if the versionable trait would use a pass through of the connection from the model to be used on the version model.

This would require that the versions table exist in any database with a versionable table contained within it, but my opinion is that the versions table should exist within all databases regardless of use (within that database).

I am currently looking through this packages code to implement a possible solution to make this work, but I have not come up with anything at the moment.

In the readme, it is mentioned that specific attributes can be blacklisted instead of whitelisting a variety of fields.

Can you please explain how this is done since it is not explicit in the readme about the process.

The docs are misleading. When I call:

$model->lastVersion;

I am expecting to get the latest version but I get the first. I see in the sources that it returns latest() relationship, so to get the latest version I have to use:

$model->lastVersion()->first();

In this case I get what I expect. Suggestion: Edit the docs or update the code

For the demo purpose I have created a repo with example. Just clone and install the dependencies. It's a fresh Laravel 9 app. Versionable model:

https://github.com/4unkur/laravel-versionable-example/blob/master/app/Models/SurveyTemplate.php

has 2 versionable fields. The strategy is SNAPSHOT

Failing test: https://github.com/4unkur/laravel-versionable-example/blob/master/tests/Feature/VersionTest.php I'm expecting that no versions will be created if the versionable fields are not touched. I don't think Snapshot strategy is the problem as in my understanding it is related to the data stored in the versions: all versionable fields or just changed ones.

Hello, when I create a record, for example a user with name "John", and it changes it to "Charles", is there any way to get the original first name, "John"? Because it seems that I can just get the changes, in this case, "Charles", but then I lose a lot of information for that first change.

Thank you so much.

https://github.com/overtrue/laravel-versionable#reversion-without-saving

here it says that the method can be used on the model but in fact the method belongs to the Version model, so the correct way of usage would be:

$version = $post->versions()->first(); // just as an example
$version->revertWithoutSaving();

This introduces the possibility to add versions manually by using createVersion() on the versionable model. This is useful if one would like to tweak a models history later on and add historical data from the past.

$post->createVersion(); // will do nothing if the model is not dirty

$post->title = 'Changed title';
$post->createVersion(); // will create a version even if versioning is disabled and the model changes are not stored (yet)

$post->createVersion(['title' => 'Changed title']); // will create a version of the model merged with the given attributes

$post->createVersion(['title' => 'very old version'], '1970-01-01') // allows to create historic versions

Because users are allowed to tweak a models version history later on the sorting has changed quite a bit. We are no longer sorting by Version.id alone. Instead created_at and id are taken into account to find previous and next versions.

And because $model->versions isn’t guaranteed to be sorted correctly anymore $model->history does exactly that:

$post->versions;
// ['id' => 1, 'title' => 'First title', 'created_at' => '2022-10-07 12:15:00']
// ['id' => 2, 'title' => 'Changed title', 'created_at' => '2022-10-07 12:30:00']
// ['id' => 3, 'title' => 'very old version', 'created_at' => '1970-01-01 00:00:00']

$post->history;
// ['id' => 2, 'title' => 'Changed title', 'created_at' => '2022-10-07 12:30:00']
// ['id' => 1, 'title' => 'First title', 'created_at' => '2022-10-07 12:15:00']
// ['id' => 3, 'title' => 'very old version', 'created_at' => '1970-01-01 00:00:00']

Please check out the tests I've added which will give a good overview of the changes.

This PR adds a versionAt() method which accepts a Carbon parseable timestamp and queries for the version that was valid at this specific time. Will return null if the timestamp is before the first version and will return the latest version if the timestamp is after the last one.

Also added some tests in VersionAtTest.php.

Hello, I have an issue when using this package through a job. I think the problem is in this line:

$version->{\config('versionable.user_foreign_key')} = \auth()->id(); line 64 in Version.php.

When running a job, auth()->id() returns null, so it throws an error and it doesnt save changes. Is there any way to fix this?

Thanks a lot.

The class names mentioned in the Custom Version Store strategy section of the README is incorrect.

- `Overtrue\LaravelVersionable::DIFF` - Version content will only contain changed attributes (Default Strategy).
- `Overtrue\LaravelVersionable::SNAPSHOT` - Version content will contain all versionable attributes values.

+ `Overtrue\LaravelVersionable\VersionStrategy::DIFF` - Version content will only contain changed attributes (default strategy).
+ `Overtrue\LaravelVersionable\VersionStrategy::SNAPSHOT` - Version content will contain all versionable attributes values.

Code change for #36.

This will allow for multiple database connections where the connection from the model with the versionable trait will pass through to the version model.

It does require that the version table exists in any database with a table that is versionable but that is the intent of this change.

When there is no connection specied (ie: null connection name) Laravel will just use the default connection.