TL;DR: A migration I shipped created a column literally named 36. It is still in production. Here are five migration mistakes from a live Laravel e-commerce store, what each one actually did to the schema, and how to repair them without downtime.
Every schema article you have read shows you the clean version — including one of mine. The tables are tidy, the indexes are deliberate, and the author implies they got it right the first time.
Here is the other half. Seven weeks after that schema went live, the cart tables had picked up four follow-up migrations, one silent bug that is still sitting in production today, and a repair migration that quietly contradicts the one before it. None of this is hypothetical: I pulled the column list off the live database while writing this.
Mistake #1: calling char() without a column name
This is the one that still makes me wince. The migration was named add_oId_selected_user_id_to_cart_items_table. The intent was obvious — add a 36-character UUID column called oId. This is what shipped:
