db(add columns): created_at #93

MikePresman · 2024-06-03T19:19:12Z

Added these columns since they are extremely helpful for tracking when a version was created

angelini · 2024-06-04T10:10:19Z

migrations/000007_add_date_columns_to_objects.up.sql

@@ -0,0 +1 @@
+ALTER TABLE dl.objects ADD COLUMN created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP NOT NULL;


I think defaulting to current timestamp is cool, we wouldn't need to add any code changes and would get created_at for free.

The only worry here is what do we do for existing rows, I kind of feel like they should be null instead of some fixed date when we rolled this out.

Can you try testing the following:

Create rows without this patch

Run this migration (without the NOT NULL part)

Do the existing rows get the date of the migration as their value or null? I suspect they'll get the date of the migration.

We might need to run a first migration with default null and then a second migration with default current_timestamp

db(add columns): created_at and updated_at

adabbd1

MikePresman force-pushed the add/datetime-to-objects branch from 6405e0b to adabbd1 Compare June 3, 2024 19:19

MikePresman changed the title ~~db(add columns): created_at and updated_at~~ db(add columns): created_at Jun 4, 2024

MikePresman requested review from angelini June 4, 2024 02:48

angelini reviewed Jun 4, 2024

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

db(add columns): created_at #93

db(add columns): created_at #93

MikePresman commented Jun 3, 2024

angelini Jun 4, 2024

		@@ -0,0 +1 @@
		ALTER TABLE dl.objects ADD COLUMN created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP NOT NULL;

db(add columns): created_at #93

Are you sure you want to change the base?

db(add columns): created_at #93

Conversation

MikePresman commented Jun 3, 2024

angelini Jun 4, 2024

Choose a reason for hiding this comment