Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

Ligonsker's avatar

Multiple updated_at columns - how to define?

I know that when using $timestamps I can have a timestamp with a last_updated_at column that updates automatically on every row change.

But what if I have multiple updated at columns:

col_x | col_x_last_updated_at | col_y | col_y_last_updated_at

how should I go about updating the matching columns? So if col_x updates, update the timestamp of col_x_last_updated_at?

Is my best option to use Events? and whenever there's an updated event dispatch, then update the necessary columns on the listener ?

0 likes
10 replies
Sinnbeck's avatar

Wont they always be 100% identical?

2 likes
Snapey's avatar
Snapey
Best Answer
Level 122

when you save a value for col_x also set the current time in the col_x_updated column

don't make it harder than it needs to be

2 likes
Ligonsker's avatar

@sinnbeck in this case they are checkboxes so you can update specific checkbox and leave the other one untouched

@snapey thanks, will just do that. The best way would be to use something like Carbon::now() on the column when using the Eloquent update statement?

1 like
Ligonsker's avatar

@pikant I don't think that is going to help in this case

In my case the goal is simply to get the timestamp of when the checkboxes were updated last (need to display it alongside the rest of the data of that row)

1 like
Tray2's avatar

One option is to create a log table that stores all the updates.

With the following columns

  • table_name
  • column_name
  • old_value
  • new_value
  • username
  • timestamps

It would look something like this.

table1		column1		0		1		Erik
table1		column2		5		4		Dan

You can use table triggers for that.

https://learn.microsoft.com/en-us/sql/t-sql/statements/create-trigger-transact-sql?view=sql-server-ver16

That is the way I would do it, you can of course handle it with php if you wish, put this kind if thing is what table triggers are for.

1 like
Ligonsker's avatar

@Tray2 this is a good option, but when I thought about it, I prefer to keep it in code because I can see it might break integrity if small changes happen, especially when I'm not in charge of the DB

Tray2's avatar

@Ligonsker I wouldn't worry about that, we use the same technique in our production databases and we register a litteral shit load of data every day, and since it's in it's own table there is no integrity issues. You just need to have the tables primary key in the log table (I forgot to add it to the illustration). You can also register the action (insert, update and delete).

Please or to participate in this conversation.