<p></p>
<p dir="auto">The <code class="notranslate">AS integer</code> bit is super interesting and surprisingly complicated!</p>
<ul dir="auto">
<li>All sequences created on postgres 9 were bigint.</li>
<li>Then <a class="commit-link" data-hovercard-type="commit" data-hovercard-url="https://github.com/postgres/postgres/commit/2ea5b06c7a7056dca0af1610aadebe608fbcca08/hovercard" href="https://github.com/postgres/postgres/commit/2ea5b06c7a7056dca0af1610aadebe608fbcca08">postgres/postgres@<tt>2ea5b06</tt></a> happened.</li>
<li>Sequences created on postgres 10+ are now either integer or bigint, depending on the type of the primary key.</li>
</ul>
<p dir="auto">We have 9 tables with <code class="notranslate">integer</code> id columns, where if you created the table on postgres 9 (veteran dev, production) the sequence will have the <code class="notranslate">bigint</code> type, but other people (new devs, CI) will have the sequence with <code class="notranslate">integer</code> type, which is also what we have in structure.sql. These 9 sequences are:</p>
<ul dir="auto">
<li>changeset_comments_id_seq</li>
<li>client_applications_id_seq</li>
<li>issue_comments_id_seq</li>
<li>issues_id_seq</li>
<li>oauth_tokens_id_seq</li>
<li>redactions_id_seq</li>
<li>reports_id_seq</li>
<li>user_blocks_id_seq</li>
<li>user_roles_id_seq</li>
</ul>
<p dir="auto">There are 3 further tables that have an additional complication:</p>
<ul dir="auto">
<li>Primary keys created on rails < 5.1 were integer by default, rails >= 5.1 primary keys are bigint by default. (<a href="https://github.com/rails/rails/blob/9c22f35440ab85718ebf48e26b8944032c737193/activerecord/lib/active_record/migration/compatibility.rb#L333">Override for old versions</a>).</li>
<li>We have three migrations to convert integer primary keys to bigint for three specific tables. When these were run on postgres 9 (veteran dev, production), we ended up with bigint sequences, since all sequences were bigint to start with. However, when these migrations are run on postgres 10+ (new dev, CI) we end up with a mismatch between primary key and sequence, since updating the primary key to bigint does not also change the sequence to bigint.</li>
</ul>
<p dir="auto">These three tables are:</p>
<ul dir="auto">
<li>oauth_nonces (db/migrate/20201214144017_expand_nonce_id.rb:4:      change_column :oauth_nonces, :id, :bigint)</li>
<li>notes (db/migrate/053_add_map_bug_tables.rb:16:    change_column :map_bugs, :id, :bigint)</li>
<li>note_comments (db/migrate/054_refactor_map_bug_tables.rb:15:    change_column :map_bug_comment, :id, :bigint)</li>
</ul>
<p dir="auto">I need to have a think about what the best thing to do is.</p>
<p dir="auto">For the first set of 9, I'm tempted to just run "ALTER SEQUENCE foo_seq AS integer;" locally, since then my machine matches CI and new devs, and although production will still be bigint I can't see any harm in that. Alternatively, we could instead upgrade the affected tables to have bigint ids, for consistency if nothing else.</p>
<p dir="auto">For the second set of 3, it's potentially confusing to new developers that the sequences are only integer despite the primary keys being bigint, and they might worry that it's also bug in production (without being able to know that production has postgres-9-era bigint sequences). It's also a gotcha for anyone else who deploys the code, since they will have a "for real" mismatch lurking in their production database. For these tables, it might be worth either adding migrations to alter the sequences to bigint (which will make no difference in production, but will fix everything else).</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />Reply to this email directly, <a href="https://github.com/openstreetmap/openstreetmap-website/issues/4298#issuecomment-1832615439">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AAK2OLMGI6WZY5GW56JF6LLYG6H27AVCNFSM6AAAAAA6FVRJH6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMZSGYYTKNBTHE">unsubscribe</a>.<br />You are receiving this because you are subscribed to this thread.<img src="https://github.com/notifications/beacon/AAK2OLLL7HSOTGDI2L4TIU3YG6H27A5CNFSM6AAAAAA6FVRJH6WGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTTNHN7A6.gif" height="1" width="1" alt="" /><span style="color: transparent; font-size: 0; display: none; visibility: hidden; overflow: hidden; opacity: 0; width: 0; height: 0; max-width: 0; max-height: 0; mso-hide: all">Message ID: <span><openstreetmap/openstreetmap-website/issues/4298/1832615439</span><span>@</span><span>github</span><span>.</span><span>com></span></span></p>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/openstreetmap/openstreetmap-website/issues/4298#issuecomment-1832615439",
"url": "https://github.com/openstreetmap/openstreetmap-website/issues/4298#issuecomment-1832615439",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>