uh the first thing I do is literally remove the down method this is something that it might sound a little bit controversial but I feel like if you want to do changes in your schema you don't call the down method you probably will do a new migration do you know what I mean so typically the first thing I do is literally remove the down method and if for any reason you would have a migration which is broken and you had to fix in production you would ideally write the new migration so you move only forward
not backwards you know what I mean so the first thing I always do is literally make sure that um I don't have it done meod that's the first thing I do important key user ID constrain it now something that I never do literally never do and I would advise you to not do that as well do you know that sometimes people say uh on delete cascading things like that I never use this like literally I never use on delate Cascades because I feel in my opinion that such as important business logic like literally cascading delites
is something that you want to control at application Level like the last thing you want in your application is having by mistake deleting a database row and then you have like your entire database disappearing um just because of that mistake you know what I mean my advice to you is that never use Cascade Elites like literally I'm scared of them because just thinking that by mistake if I delete the database row everything could Cascade down just scared me you know what I mean so if I were to run you know a delete on this database
row it will start to complain because there is still rows on the table B and if I try to do the table B row will still complain because there is still stuff on the table C and what this allows me to think a little bit is that when I'm firing my action on my actions folder to delete this project this table a it will force me to go to every single table and explicitly and manually delete the the information first uh before I actually delete the final one which is on the table a you know
what I mean so I don't I don't actually like to tie my migrations with my actual code so the problem if you if you were to do something like this the problem is that if you for any reason were to change the user model to a different name for example person or you know potentially team for for example uh that will affect your migrations even the oldest ones so you want to make sure that you don't you know you don't tie up your U migrations with actual domain logic there is multiple reasons why I don't
like soft deletes okay um I can tell you one of the reasons if you want to uh one of the reasons is literally when you have uh unique constraints in your database so I'm going to tell you an example um if you were to have for example a unique constraint on a database uh name for examp example okay and you were to soft delete this row you know if you were to soft delete this if you were to reuse this name l in the future you cannot to because this this literally this column is soft
deleted on the database but aren actually deleted this is just one example so the views this is something that not not a lot of people do but um the views number will be big and we know the views number will be big so something we want to use here is literally a big a big integer already or even an unsigned big integer which is way bigger than that so unsigned means bigger than zero okay unsigned means basically you cannot have negative integers within this column within this column value that's what unsigned means okay and bigger
integer is a bigger in is a bigger integer than the regular one I can just tell you that it's a much bigger integer to be honest and something I never do this is something I want to speak with you about is that I never use defaults okay I never use defaults for multiple reasons really on my actions I'm also I'm always specifying the default values for my columns when I'm creating for example a project I want to have the most business logic as possible within my actions in not magically appearing from my migrations uh table
string which is a plan something I want to do is type oh I'm going to just type uh the default of this will be free you know what I mean cuz if you do this you are effectively coupling a little bit of the business logic to your migrations again so if in the future the default plan were not to be anymore uh the free one it were to be like something else uh will be kind of complicated to change migrations you want you want to avoid that as much as possible uh so what I do
here is that I usually never use a default method and I kind of force everyone to specify what should be by default on my action which creates the project itself you know what I mean
