[openstreetmap/openstreetmap-website] Align structure.sql with generated output (Issue #4298)

[Andy Allan]

For the `timestamp(6)` on `ar_internal_metadata`, the structure.sql should continue to use `timestamp(6)`.

This is because for rails 6.0+, timestamp(6) is the default for timestamp columns. ([default](https://github.com/rails/rails/blob/87c42b2c4f0cd287323eae4c3e0e2f47a7635585/activerecord/lib/active_record/connection_adapters/abstract/schema_statements.rb#L1824) vs [override for old versions](https://github.com/rails/rails/blob/87c42b2c4f0cd287323eae4c3e0e2f47a7635585/activerecord/lib/active_record/migration/compatibility.rb#L255-L258)) All of our migrations are correctly labelled with which AR version to use, so tables before that are defined with `timestamp`, tables after that with `timestamp(6)`.

The edge case is that `ar_internal_metadata` table is not controlled, so gets the defaults at the moment it was created, which varies from system to system. On my laptop that was before rails 6, so I have `timestamp`. Any developer who first ran the code after [November 2019](https://github.com/openstreetmap/openstreetmap-website/commit/22cd2314e52373d8fbe84a082c3ed058dfea8d40) will have `timestamp(6)`.

I've updated my development machine, by running:

```
alter table ar_internal_metadata alter column created_at set data type timestamp(6) without time zone;
alter table ar_internal_metadata alter column updated_at set data type timestamp(6) without time zone;
```

I would encourage any other veteran developers to run the same update, to avoid noise when working on database migrations.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/openstreetmap/openstreetmap-website/issues/4298#issuecomment-1832194246
You are receiving this because you are subscribed to this thread.

Message ID: <openstreetmap/openstreetmap-website/issues/4298/1832194246 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/rails-dev/attachments/20231129/21adcc6b/attachment.htm>