<p></p>
<blockquote>
<p>I did in fact try out to use squasher around last December/January for this project but ran into errors that looked like they are PostgreSQL related … or maybe had something to do with special indexes or primay keys(?) (It might be the same as the composite_primary_keys gem you guys talk about in the Rails6.1 branch).</p>
</blockquote>
<p>I got squasher working today - you can see the results at <a class="commit-link" data-hovercard-type="commit" data-hovercard-url="https://github.com/gravitystorm/openstreetmap-website/commit/9890f754c012266617000c1fca025a93bd432ac4/hovercard" href="https://github.com/gravitystorm/openstreetmap-website/commit/9890f754c012266617000c1fca025a93bd432ac4">gravitystorm@<tt>9890f75</tt></a> . The trick was to add a <code>create_extension "btree_gist"</code> to the first migration, since squasher creates its own database automatically, and that extension is needed for some index stuff later in the 028 migration. The primary key and enum monkey patching doesn't seem to cause any problems.</p>
<p>So squasher seems like a reasonable compromise between removing all the old migrations, but without having to change any workflows, since <code>rake db:migrate</code> will still work on an empty database. I'm interested to hear what other people think?</p>
<p>Additional points to consider:</p>
<ul>
<li>Should we include the squasher 'cleanup' migration, which removes the no-longer-required entries from the <code>schema_migrations</code> table?</li>
<li>Need to update rubocop config, and check that the output schema matches the migrations (in case there's an edge case in the sql format dumping) since there are test failures.</li>
<li>I'm also interested if we can move away from SQL format db dumps, which are quite verbose files. There's a <a href="https://github.com/alassek/activerecord-pg_enum">pg_enum gem</a> that could replace our custom enum code, and that also knows how to dump the enum information back into schema.rb files. If we're also removing the functions, is there anything left that needs SQL format dumps?</li>
<li>If we decide all this is a bad idea and abandon this work, we should at least remember to add <code>create_extension "btree_gist"</code> to the appropriate migration and simplify our install instructions <g-emoji class="g-emoji" alias="smile" fallback-src="https://github.githubassets.com/images/icons/emoji/unicode/1f604.png">😄</g-emoji>.</li>
</ul>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/openstreetmap/openstreetmap-website/issues/3110#issuecomment-795797903">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AAK2OLJTHSYNNRZDGKXQFF3TC6VFXANCNFSM4YFH7W4A">unsubscribe</a>.<img src="https://github.com/notifications/beacon/AAK2OLJM7R3OLB3322KCKW3TC6VFXA5CNFSM4YFH7W4KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOF5XOTDY.gif" height="1" width="1" alt="" /></p>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/openstreetmap/openstreetmap-website/issues/3110#issuecomment-795797903",
"url": "https://github.com/openstreetmap/openstreetmap-website/issues/3110#issuecomment-795797903",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>