<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Not a Rails answer, as I’m in the TypeScript world at the moment, but the principles may apply:<div class=""><br class=""></div><div class="">For the last 6 months or so, we’ve taken to dropping the entire schema and re-running all migrations on startup & hot-reload. This is very common for test envs, but actually works surprisingly well in development to, for the same reasons it’s recommended for tests. The only two caveats we’ve found so far:</div><div class=""><br class=""></div><div class="">1. It doesn’t prevent developers from modifying past migrations, meaning everything will work as expected in dev/test, but the migration won’t be applied in staging/prod</div><div class="">2. It can start slowing down if you have large amounts of seed data. One of our systems requires 10k rows to be present in a given table, and it can take 1-5s each time it gets seeded. <br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 1 Mar 2021, at 09:47, Ed James <<a href="mailto:ed.james.spam@gmail.com" class="">ed.james.spam@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Some surprising behaviour to be aware of when using “db:schema:load” which has caught us out a few times before…<div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">Create a new branch, add a migration on your branch and run the migration. Commit the change.</li><li class="">Go back to your “master” branch.</li><li class="">Run “rake db:schema:load”</li><li class="">You’d think at this point that the migration on your feature branch would’ve been “reset”, but…</li><li class="">Check out your feature branch again and try to apply your migration. Nothing will happen.</li></ul><div class=""><br class=""></div><div class="">When you run “db:schema:load” it doesn’t touch the data in your “schema_migrations” table but it obviously does touch your db schema! So in the example above, the migration version will still be present in your “schema_migrations” table but the actual change will not have been applied to your db => busted db and much pain and suffering.</div><div class=""><br class=""></div><div class="">Hopefully this helps someone :) </div><div class="">
<br class="">
<hr style="display: block; height: 1px; border: 0; border-top: 1px dotted #ccc; margin: 5px 0; padding: 0;" class="">
<br class="">
<table border="0" cellpadding="0" width="100%" class="">
<tbody class="">
<tr class="">
<td valign="top" width="70" class="">
<img height="60" src="http://ej-public.s3.amazonaws.com/images/rubbish.png" style="margin: 8px 8px 0 0;" class="">
</td>
<td style="font-family:'Lucida Grande',sans-serif" class="">
<span style="font-weight:bold; color: #333333; font-size: 18px; line-height:30px;" class="">Ed James</span>
<br class="">
<span style="font-weight:normal; color: #999; font-size: 12px; line-height:16px;" class="">
<a href="mailto:ed.james.spam@gmail.com" style="color:#999; text-decoration:none" target="_blank" class="">I will respect your spam</a>
</span>
</td>
</tr>
</tbody>
</table>
</div>
<div class=""><br class=""><blockquote type="cite" class=""><div class="">On 1 Mar 2021, at 08:18, Patrick Gleeson <<a href="mailto:patrick.c.gleeson@gmail.com" class="">patrick.c.gleeson@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Step one: Whoever yells loudest gets to keep their database<div class="">Step two: Everyone else does rails db:reset on their development databases, and possibly just db:schema:load on their test ones if you have seed data you don't want in your test db.</div><div class=""><br class=""></div><div class="">The key is that db:schema:load reads from the schema file as-is, rather than reading from the migrations and re-constructing the schema from the database.</div><div class=""><br class=""></div><div class=""> - Patrick</div><div class=""><br class=""></div><div class=""><a href="https://whyarentyoucoding.com/" class="">Why aren't you coding?</a></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 1 Mar 2021 at 08:10, Stuart Harrison <<a href="mailto:pezholio@gmail.com" class="">pezholio@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class=""><div class="">Morning LRUG</div><div class=""><br class=""></div><div class="">I wanted to share an annoyance I've had on multiple projects, and wondered if anyone had any fixes for it? <br class=""></div><div class=""><br class=""></div><div class="">If there are multiple devs on a project committing a bunch of migrations and running `db:migrate`, it seems that, over time, the order of columns in the schema.rb file jumps around every time the command is run. <br class=""></div><div class=""><br class=""></div><div class="">I can get around this by only committing the relevant line(s) when I run a migration, but this does get annoying. <br class=""></div><div class=""><br class=""></div><div class="">I'm sure there is a solution, but it's disappeared out of my head, and seems to be an ungoogleable problem, so was wondering if anyone had come across a solution?</div><div class=""><br class=""></div><div class="">Cheers</div><div class=""><br class=""></div><div class="">Stu<br class=""></div></div>
_______________________________________________<br class="">
Chat mailing list<br class="">
<a href="mailto:Chat@lists.lrug.org" target="_blank" class="">Chat@lists.lrug.org</a><br class="">
Archives: <a href="http://lists.lrug.org/pipermail/chat-lrug.org" rel="noreferrer" target="_blank" class="">http://lists.lrug.org/pipermail/chat-lrug.org</a><br class="">
Manage your subscription: <a href="http://lists.lrug.org/options.cgi/chat-lrug.org" rel="noreferrer" target="_blank" class="">http://lists.lrug.org/options.cgi/chat-lrug.org</a><br class="">
List info: <a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" rel="noreferrer" target="_blank" class="">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br class="">
</blockquote></div>
_______________________________________________<br class="">Chat mailing list<br class=""><a href="mailto:Chat@lists.lrug.org" class="">Chat@lists.lrug.org</a><br class="">Archives: <a href="http://lists.lrug.org/pipermail/chat-lrug.org" class="">http://lists.lrug.org/pipermail/chat-lrug.org</a><br class="">Manage your subscription: <a href="http://lists.lrug.org/options.cgi/chat-lrug.org" class="">http://lists.lrug.org/options.cgi/chat-lrug.org</a><br class="">List info: <a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" class="">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br class=""></div></blockquote></div><br class=""></div></div>_______________________________________________<br class="">Chat mailing list<br class=""><a href="mailto:Chat@lists.lrug.org" class="">Chat@lists.lrug.org</a><br class="">Archives: http://lists.lrug.org/pipermail/chat-lrug.org<br class="">Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org<br class="">List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org<br class=""></div></blockquote></div><br class=""></div></body></html>