Allow configuration to DISABLE updating the updated_at timestamp during mass update?

[stevenmaguire]

A common use case of mine is to perform mass updates to models where you DO NOT want to touch the updated_at timestamp. Are you open to supporting that use case with this library?

[iksaku]

Hello Steven. I intend for this method to stick as close as possible to Laravel's Model::query()->update() method. As natively there's no option to tell the query builder not to touch UPDATED_AT timestamp, I think I'll refrain from providing that option myself.

[stevenmaguire]

I appreciate where you're coming from with that. I think it is worth noting that Laravel's default behavior allows (WITH CONFIGURATION) the very behavior I am asking about. For instance...

https://laravel.com/docs/9.x/eloquent#muting-events

https://laravel.com/docs/9.x/eloquent#saving-a-single-model-without-events

https://github.com/laravel/framework/blob/213074f15e6398137e0b7cf1809368e62b0c03f1/src/Illuminate/Database/Eloquent/Model.php#L350

The model itself is capable of being told to ignore touch during save.

---

I am not advocating for the DEFAULT behavior to change. I am advocating for the behavior to be available with configuration.

[iksaku]

Doing configuration-based behavior is a good idea, not going to lie, however, ignoring timestamp updates dynamically is still not a feature with Laravel.

The code provided in Model::isIgnoringTouch() is intended for use with relationships, and if we rely on such function, unexpected behavior will arise sooner or later:
https://github.com/laravel/framework/blob/213074f15e6398137e0b7cf1809368e62b0c03f1/src/Illuminate/Database/Eloquent/Model.php#L321-L371

This library currently checks for the ability to update timestamps from the Model itself:

laravel-mass-update/src/MassUpdatable.php

Lines 214 to 216 in 5a8bda6

	if ($this->usesTimestamps() && $this->getUpdatedAtColumn() !== null) {
	$compiledUpdateStatements[$this->getUpdatedAtColumn()] = $this->freshTimestampString();
	}

It should be possible to open a PR to Laravel directly to allow this kind of configuration-based behavior and have the existing functions pickup such configuration.

I would strongly suggest looking into the possibility of integrating such feature at framework level and this library would automatically pickup your desired behavior without causing edge-cases.

[stevenmaguire]

I get it. Following the stock Laravel convention is definitely a safe way to go. The stock Laravel behavior does support this via the HasTimestamps trait.

The expectation is that the configuration is operating against an instance. If you were operating against a single instance of a model, the following would disabled timestamp touching (directly, not relations):

$model->timestamps = false;
$model->save(); // No updated_at modification
$model->timestamps = true;
$model->save(); // With updated_at modification

The trouble is arrises with this comment that decorates the method you've highlighted:

laravel-mass-update/src/MassUpdatable.php

Line 213 in 5a8bda6

// If the model tracks an update timestamp, update it for all touched records.

In other words, "if the [AUTOMATICALLY INSTANTIATED] model ($this) has $this->timestamps == true (which it most certainly does by default, unless someone goes out of their way to override that for a model, for all of their default use cases)" then the "update it for all touched records" portion of the comment will always touch the timestamps.

This is a troubling use case, for sure and I haven't seen any other library attempt it as part of the library's API. The most popular one (at the moment) is mavinoo/laravel-batch and it steers clear of "model-attached" ergonomics (it does not furnish a static method, scope or otherwise) but still leverages a freshly instantiated model for direction on how to map data.

It stands to reason that the following would - hopefully - work for this library:

$model = new Model();
$model->timestamps = false;
$model->massUpdate(
    values: [
        ['id' => 1, 'name' => 'Jorge González'],
        ['id' => 2, 'name' => 'Gladys Martínez'],
    ]
);
$model->timestamps = true;

I just don't see test cases to support that and, ergonomically speaking, it is a bit cumbersome.

Perhaps a third parameter that accepts some configuration could tidy that up?

Model::massUpdate(
    values: [
        ['id' => 1, 'name' => 'Jorge González'],
        ['id' => 2, 'name' => 'Gladys Martínez'],
    ],
    uniqueBy: 'username',
    options: ['timestamps' => false]
);

Or a fluent setter that resets after each "massUpdate" - to avoid the "turn it off" then "turn it on" convention disclosed above?

Model::withoutMassUpdateTimestamp()->massUpdate(
    values: [
        ['id' => 1, 'name' => 'Jorge González'],
        ['id' => 2, 'name' => 'Gladys Martínez'],
    ],
    uniqueBy: 'username'
);

[cwilby]

@stevenmaguire @iksaku just an FYI - I'm currently testing a couple of approaches to perform mass updates quietly.

Here are the candidates:

Model::withoutMassUpdateTimestamps()->massUpdate(...);

Model::massUpdateQuietly(...);

trait MassUpdatable
{
    public static function withoutMassUpdateTimestamps(): self
    {
        return tap(new static(), function (self $model) {
            $model->timestamps = false;
        });
    }    
    
    public function scopeMassUpdateQuietly(Builder $query, array | Arrayable $values, array | string | null $uniqueBy = null): int
    {
        $this->timestamps = false;

        return tap($this->massUpdate($query, $values, $uniqueBy), function () {
            $this->timestamps = true;
        });
    }
}

[cwilby]

PR with tests: https://github.com/iksaku/laravel-mass-update/pull/6/files

@stevenmaguire this is mostly a porting of your legwork into code - thank you!

[stevenmaguire]

@cwilby awesome! that looks promising - thanks for investing the elbow grease. I'm glad to hear my chicken scratch proved useful, perhaps inspiring. It looks like you closed the PR?

[stevenmaguire]

I still think there is room, and use case for smoothing out the ergonomic friction with this library. Under the hood it can, and should, use Laravel's stock features. IMO the Model::withoutTimestamps(fn () => Model::massUpdate(...)); approach is still clunky.

I think the Model::massUpdateQuietly(...); add here is still valuable, even if the underlying approach is different than what you previously proposed.

Your branch was right there! Perhaps a second pass to introduce that method as first-party support - with your tests! - will be acceptable?

[cwilby]

Reopened ¯_(ツ)_/¯

[stevenmaguire]

I just added a comment!

[iksaku]

PR merged and tagged the 1.0.5 release 🥳

[stevenmaguire]

Thank you @iksaku and @cwilby - great work!