RE: Using Seeders Use migrations for creating REQUIRED data such as foreign key tables for enums, or adding new data to existing tables (static data that is always required, status table for example). Seeders are good for adding demo / scaffolding data, however are not easily reversed in a production environment
Another great video! It was very difficult for me to work in team for the first time. If I had found video like this one, I think everything would be better ... Only one thing I prefer in another way: I use guarded instead of fillable and throw 'id' as first element of array (to prevent overwrite). In that case, if someone add new column in table, the column should be not declared in fillable. Yes, is not so readable, but is more easy and (still) secure and I provide a case of my experience - one of my teammates add new column in existing table with dozen of relations (the most of relations was not cascade) and for some reason he did not delcared it in fillable. I pull and try to create new record in db and Laravel throw me error - this column is not fillable. So, from this moment, I just add (for most projects) trait with protected $guarded = ['id'] and use this trait in base class. Thanks for the great video, Mr. Korop!
Thanks for the comment, I partly agree with you that $fillable is more risky if someone forgets to fill that in, but I prefer readability and clarity. Personal preference :)
In the part form request is good practice make one request for model ? for example make:request UserRequest and apply switch case with methods (get, post, put, patch, deleite, whatever method).
16:50 - i will even go further - the code which breaks a tests - should be never merged, or even pushed to branch, "master" branch should always be green
The thing to avoid n+1 queries in production won't be too useful unless you're using a DBaaS (where every query counts). The load to the database should be the same if you are careful with that in development but if depending on how its implemented it could just lead to a lot of "this works in dev but not in production for some reason" situations.
Very helpful tips.. thanks 😊 Just wanted to know, how to create or maintain the UML diagrams for the big project and documentation of the flow of code in laravel...
Confluence is usually the best place for documentation. There's plugins for all sorts of diagrams, including UML. Alternatively, there's other online tools (e.g. Lucid Chart) plus some db software can also export it by analysing the database itself.
I know it's an old video, but I faced aproblem recently: dev1 working on feature_1, dev2 working on feature_2 at the same time. Dev1 creates some migrations and execute it on his machine. Dev2 do the same, but dev2's migrations are create before dev1's. So when both merge their work, and dev1 will run migration, to migrate dev2 work, nothing is migrated due to the date of creation of that migrations. Is there a way to solve this?
It should not matter if migrations are created before or after, Laravel checks for any migration files that were not executed. So something is wrong in your exact situation, can't answer in a TH-cam comment, needs debugging.
Don't want to be over on easy thing, but when working with other people, don't be lazy on naming more helpful commit, add a little description if the commit not obvious. Take some time to add comments for the commit if using cloud repository
For your own dev or code build by other team members, especially still in active dev, I think it's normal.. but that's why need to ask/consult with team members..
I think I disagree with editing migrations. In a project that isn't in production, you should always edit existing migrations. Most db changes happen in development and if you keep adding new migrations you could end up with a thousand migrations by the time the project is ready to launch. Everyone should be running migrate:fresh in development constantly. So editing migrations shouldn't be a problem. Then once the project is in production, switch to adding migrations for db changes. That is what migrations are primarily for, safely updating production environments.
That's only valid when you're working alone on a project, but working with a team, you should always make a new one so that they know what's changed aswell, not just you, unless you're woking on something they won't touch.
@@ichijofestival2576 That is how I treat migrations after an application goes live. I'm also a lead dev and I guess my theory is that with TDD the tests start with a fresh database and the right data is added with factories for the test anyway. There is no reason to have persistant data in your local db. And every time I have allowed for that to happen, then devs have coded to their local data rather than properly replicate it with factories for tests. So before a site is live I prefer to make every dev fully aware that they should expect to wipe and reseed their local at any moment. It forces them to properly seed their testing data. Also I prefer to read migrations than a dump when we are at "starting point". But maybe that is just preference.
@@TYPOlight security problems, there were a few exploits for composer already, also most of the time you just don't need it, you can install dependencies during CI/CD and deploy only a code without composer on live server
RE: Using Seeders
Use migrations for creating REQUIRED data such as foreign key tables for enums, or adding new data to existing tables (static data that is always required, status table for example).
Seeders are good for adding demo / scaffolding data, however are not easily reversed in a production environment
Another great video! It was very difficult for me to work in team for the first time. If I had found video like this one, I think everything would be better ...
Only one thing I prefer in another way:
I use guarded instead of fillable and throw 'id' as first element of array (to prevent overwrite). In that case, if someone add new column in table, the column should be not declared in fillable. Yes, is not so readable, but is more easy and (still) secure and I provide a case of my experience - one of my teammates add new column in existing table with dozen of relations (the most of relations was not cascade) and for some reason he did not delcared it in fillable. I pull and try to create new record in db and Laravel throw me error - this column is not fillable. So, from this moment, I just add (for most projects) trait with protected $guarded = ['id'] and use this trait in base class.
Thanks for the great video, Mr. Korop!
Thanks for the comment, I partly agree with you that $fillable is more risky if someone forgets to fill that in, but I prefer readability and clarity. Personal preference :)
Thanks! I'll see it later.
awesome, love it, thank you LD
thank you it is very helpful
This video will definitely help me
Thank you very much.
In the part form request is good practice make one request for model ? for example make:request UserRequest and apply switch case with methods (get, post, put, patch, deleite, whatever method).
It's a personal preference, but I create separate ones - StoreUserRequest and UpdateUserRequest. For other methods, I don't use requests.
Thank you for useful tips
16:50 - i will even go further - the code which breaks a tests - should be never merged, or even pushed to branch, "master" branch should always be green
The thing to avoid n+1 queries in production won't be too useful unless you're using a DBaaS (where every query counts). The load to the database should be the same if you are careful with that in development but if depending on how its implemented it could just lead to a lot of "this works in dev but not in production for some reason" situations.
Great tips. Thanks.
Very helpful tips.. thanks 😊
Just wanted to know, how to create or maintain the UML diagrams for the big project and documentation of the flow of code in laravel...
Confluence is usually the best place for documentation. There's plugins for all sorts of diagrams, including UML. Alternatively, there's other online tools (e.g. Lucid Chart) plus some db software can also export it by analysing the database itself.
How to remove constraints using migration when data is already present.
Nice tips. Thanks for that
All good
I know it's an old video, but I faced aproblem recently: dev1 working on feature_1, dev2 working on feature_2 at the same time. Dev1 creates some migrations and execute it on his machine. Dev2 do the same, but dev2's migrations are create before dev1's. So when both merge their work, and dev1 will run migration, to migrate dev2 work, nothing is migrated due to the date of creation of that migrations. Is there a way to solve this?
It should not matter if migrations are created before or after, Laravel checks for any migration files that were not executed. So something is wrong in your exact situation, can't answer in a TH-cam comment, needs debugging.
Thank you so much
Don't want to be over on easy thing, but when working with other people, don't be lazy on naming more helpful commit, add a little description if the commit not obvious. Take some time to add comments for the commit if using cloud repository
you are best
Thanks
Sir, is it normal, to analyze how app or code works without any documentation and README files?
For your own dev or code build by other team members, especially still in active dev, I think it's normal.. but that's why need to ask/consult with team members..
for admin users I prefer making an interactive command, this way I'm sure the password is never committed and I won't forget to change it
I think I disagree with editing migrations. In a project that isn't in production, you should always edit existing migrations. Most db changes happen in development and if you keep adding new migrations you could end up with a thousand migrations by the time the project is ready to launch.
Everyone should be running migrate:fresh in development constantly. So editing migrations shouldn't be a problem.
Then once the project is in production, switch to adding migrations for db changes. That is what migrations are primarily for, safely updating production environments.
That's only valid when you're working alone on a project, but working with a team, you should always make a new one so that they know what's changed aswell, not just you, unless you're woking on something they won't touch.
@@patrick-dev that is what git is for. Migrations are just like any other code. If you want to see what changed check the commits.
@@ichijofestival2576 That is how I treat migrations after an application goes live.
I'm also a lead dev and I guess my theory is that with TDD the tests start with a fresh database and the right data is added with factories for the test anyway. There is no reason to have persistant data in your local db. And every time I have allowed for that to happen, then devs have coded to their local data rather than properly replicate it with factories for tests.
So before a site is live I prefer to make every dev fully aware that they should expect to wipe and reseed their local at any moment. It forces them to properly seed their testing data.
Also I prefer to read migrations than a dump when we are at "starting point". But maybe that is just preference.
11:10 honestly - you should never have composer binary on live server
Why? Really, I'm curious.
@@TYPOlight security problems, there were a few exploits for composer already, also most of the time you just don't need it, you can install dependencies during CI/CD and deploy only a code without composer on live server
@@TYPOlight The same as idea of least privileges. less software - less attack vectors