skipAttributes() and getChangedFields() are confusing

[s-ohnishi]

I created the table below.

CREATE TABLE users
(
     id INT UNSIGNED NOT NULL AUTO_INCREMENT,
     name VARCHAR(255),
     createdAt DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
     updatedAt DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
     PRIMARY KEY (id)
);

The following models are available for this purpose.

class Users extends \Phalcon\Mvc\Model
{
     protected ?int $id = null;
     protected string $name = '';
     protected string $createdAt;
     protected string $updatedAt;

     public function initialize()
     {
         $this->skipAttributes(['createdAt', 'updatedAt']);
         $this->useDynamicUpdate(true);
     }
}

Then, after registering a suitable user, execute the following and you will get satisfactory results.

     $user = Users::findFirst(1);
     $user->setName('John');
     var_dump($user->getChangedFields()); // ['name']
     $user->save();
     var_dump($user->getChangedFields()); // []

However, for newly created users, the results are unsatisfactory.

     $newUser = new Users();
     var_dump($newUser->getChangedFields()); // ['id', 'name', 'createdAt', 'updatedAt']
     $newUser->assign(['name'=>'Jane']);
     $newUser->save();
     var_dump($newUser->getChangedFields()); // ['createdAt', 'updatedAt']

Wouldn't it be desirable to return an empty array after $newUser->save()?
I think it's a problem that the behavior changes between existing records and new records.
For existing records, dirtyState remains 0 even if the field value is changed, and for new records, getChangedFields() does not become empty even after saving.
As a result, each case needs to be checked separately.
Maybe it's because I set the fields to skip with skipAttributes(), but isn't that a normal thing?

Is there any other way to check that a record has been saved without being confused by these situations?

[corentin-begne]

Just check the result of the save(), if it's false that mean it failed then check errors withh getMessages :
https://docs.phalcon.io/5.0/en/db-models#overview

[s-ohnishi]

thank you for your reply.
I thought I had checked this during the test, but I checked again just to be sure.
In both cases, save() returns true.

For $user, after executing save(), the value of updatedAt will be updated by ON UPDATE CURRENT_TIMESTAMP (confirmed).
However, getChangedFields() returns an empty array.
This result is understandable.

For $newUser, getChangedFields() returns ['createdAt', 'updatedAt'] after executing save() (returning true).
This does not seem to reflect the specification in skipAttributes(), and is not the expected value.
I think new records should be treated the same way as existing records.

By the way, 'createdAt' and 'updatedAt' specified in skipAttributes() do not exist in the result of getUpdatedFields() after save().

[corentin-begne]

Maybe this is because mysql update the fileds itself, try to use addBehavior instead. In mysql newest version you can't have multiple columns with default current_timestamp anyway, usually updated_at is nullable like :

  `created_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `updated_at` timestamp NULL DEFAULT NULL

https://github.com/corentin-begne/phalconTool/blob/master/src/ModelBase.php#L237

[s-ohnishi]

In mysql newest version you can't have multiple columns with default current_timestamp anyway

This was the case in old MySQL, but it should now work for multiple columns.
There is also an example of setting for multiple columns in the official manual.
https://dev.mysql.com/doc/refman/8.0/en/timestamp-initialization.html

mysql update the filed itself

Isn't MySQL itself setting values the same for new records and existing records?
However, it doesn't make sense that the results are different.

[corentin-begne]

Didn't know it, i've got the pb when updating mysql version, so blocking, then I understood that was a bad practise.
Yes but maybe that the ORM don't manage it the same way with empty empty values at first, I agree that there's a pb but test behaviors maybe it could resolve the pb and you'll can let your default values.

[s-ohnishi]

I'm sorry, but I'm not good at English.
What does "PB" mean?

test behaviors maybe it could resolve the pb and you'll can let your default values.

Modern MySQL allows you to set timestamps on multiple columns, so I don't have to do anything explicitly with them.
The problem is that even though I'm trying to get Phalcon to exclude it from being checked (MySQL does it automatically), it doesn't work for new records.