reason in updated() event

[lsmith77]

I am using the reason inside an updated event. It seems like reason is reset before this event is triggered, So I figured I just fetch it from the current version, but for some (likely stupid) reason, I sometimes then get the previous and not the current version. I assume there is some caching going on, so I wonder how I can reliably ensure I get the actual current version and not some cached instance that is no longer valid after the update?

public function updated(Foo $foo)
{
    $version = $foo->currentVersion();
    $action = $version->reason;

[nonoesp]

Hey, Lukas @lsmith77!

I haven't had this need so far and don't have a clue on how to solve this.

Not sure if @mpociot might be able to help here, (even though he's not officially maintaining this package).

Please let us know if you find a solution (or fix) for your problem.

[lsmith77]

my hacky workaround is to set the reason as a static property in my observer in the updating method so that I can read it in the updated method.

[edwinvdpol]

I guess this has something to do that the old model is still loaded.

You can try the following (untested):

public function updated(Foo $foo)
{
    $foo->refresh(); // Fresh data from the database
    $version = $foo->currentVersion();
    $action = $version->reason;
}

Documentation: https://laravel.com/docs/8.x/eloquent#refreshing-models

[lsmith77]

yeah .. totally makes sense .. and I tried that as well and again just now. but it doesn't get me the latest version.

I also tried $version->refresh();

[benms]

The problem in datetime, if we make changes very fast we got the same created_at time and as result we take wrong Model data.
When I saw tests from this project, I noticed that author made sleep for 1 second after each changes for tested model.
https://github.com/mpociot/versionable/blob/master/tests/VersionableTest.php#L67
As solution we can get current version by last version_id - $foo->versions()->orderByDesc('version_id')->first()

[nonoesp]

That's awesome, @benms. It'd be great if this solves the issue, and it'd make sense to use a timestamp that is not second-based to avoid this bug.