0

I've been creating tables using migrations per the documentation, and now I've rebuilt a section of my website and now I don't need one of my older tables.

I could:

A) Create a new migration file and tell it to drop the table in the "up" function, which doesn't make semantic sense, but does make sense from a procedural standpoint.

or

B) I can manually run a rollback on that specific migration, which does make sense semantically, but doesn't make sense procedurally and requires a manual action using CLI, meaning anyone using this software ever has extra steps unless I also remove the migration file, which now makes this not makes sense semantically, and if someone issued a reset there would be missing migrations.

Is there a better option that I'm missing?

Citizen
  • 12,430
  • 26
  • 76
  • 117
  • If you're really worried about messing something up by removing this table, why not just leave it? Is there a reason you absolutely need it removed from your database? – Tim Lewis Mar 31 '15 at 18:03
  • I'm not worried at all about messing something up by removing it. I'm asking for the best practice for removing tables using Laravel. The documentation covers best practices for adding and updating tables, but not removing them. – Citizen Mar 31 '15 at 18:04
  • Ah, I see. Like Joseph said, removing them in `up` is fine. – Tim Lewis Mar 31 '15 at 18:12

1 Answers1

1

Dropping a table in up makes perfect semantic sense.

You should be dropping the table in up, and recreating the table in its current form in down.

La perfection soit atteinte non quand il n'y a plus rien à ajouter, mais quand il n'y a plus rien à retrancher.

Joseph Silber
  • 214,931
  • 59
  • 362
  • 292