That is a good point. The timestamp defaults to the current time if a
value is not given for the column during an UPDATE, but if a value is given
for the column, that is used instead. (A MySQL console session showing
this is below.)
I can work on a PR to include an :extra key in the schema output.
Thanks,
Ben
MariaDB [rightway]> CREATE TABLE test (id integer NOT NULL AUTO_INCREMENT,
name varchar(255), updated_at datetime ON UPDATE CURRENT_TIMESTAMP, PRIMARY
KEY (id));
Query OK, 0 rows affected (0.027 sec)
MariaDB [rightway]> INSERT INTO test (name) VALUES ("ben");
Query OK, 1 row affected (0.017 sec)
MariaDB [rightway]> SELECT * FROM test;
+----+------+------------+
| id | name | updated_at |
+----+------+------------+
| 1 | ben | NULL |
+----+------+------------+
1 row in set (0.000 sec)
MariaDB [rightway]> UPDATE test SET name = "BEN" WHERE id = 1;
Query OK, 1 row affected (0.003 sec)
Rows matched: 1 Changed: 1 Warnings: 0
MariaDB [rightway]> SELECT * FROM test;
+----+------+---------------------+
| id | name | updated_at |
+----+------+---------------------+
| 1 | BEN | 2021-11-13 14:44:04 |
+----+------+---------------------+
1 row in set (0.000 sec)
MariaDB [rightway]> UPDATE test SET name = "Ben", updated_at = "2020-10-11
12:00:00" WHERE id = 1;
Query OK, 1 row affected (0.014 sec)
Rows matched: 1 Changed: 1 Warnings: 0
MariaDB [rightway]> SELECT * FROM test;
+----+------+---------------------+
| id | name | updated_at |
+----+------+---------------------+
| 1 | Ben | 2020-10-11 12:00:00 |
+----+------+---------------------+
1 row in set (0.000 sec)
On Saturday, November 13, 2021 at 9:36:51 AM UTC-6 Jeremy Evans wrote:
> On Sat, Nov 13, 2021 at 6:53 AM Ben Schmeckpeper <ben.schm...@gmail.com>
> wrote:
>
>> Good morning.
>>
>> When querying a MySQL table's schema, I would like to know if a column
>> has ON UPDATE CURRENT_TIMESTAMP set.
>>
>> I found an earlier question where it was explained that MySQL's usage of
>> that syntax is non-standard and not supported for table creation, which I
>> understand. Would it be reasonable, though, to add this syntax to the
>> strings looked for in Extras when determining if a column is generated?
>> https://github.com/jeremyevans/sequel/blob/1afc503f591127755e5316cf2fbd12d9de12a85d/lib/sequel/adapters/shared/mysql.rb#L530
>>
>> If not, and the desire is for the value of that generated field to only
>> match columns that can be created using the generated_always_as option, is
>> there another way to access the Extra data provided by MySQL, or would I
>> need to run the DESCRIBE query and parse the output myself?
>>
>
> I'll have to try out this feature and see how it works. If it always
> updates to the desired value, regardless of the value you put in, then
> having it as a generated column is fine. If it only updates by default,
> but will not override a value explicitly given during the update, then it
> isn't generated in the same way the other columns marked as generated are,
> and I don't think it would be a good idea to mix the two concepts.
>
> It is possible to expand the schema entries on MySQL to include an :extra
> key. It's also possible to expand table creation on MySQL to support ON
> UPDATE CURRENT TIMESTAMP.
>
> Thanks,
> Jeremy
>
--
You received this message because you are subscribed to the Google Groups
"sequel-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sequel-talk+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sequel-talk/52d51c7a-902d-4ded-9daf-f7b2bb170aabn%40googlegroups.com.
