Thanks for the intresting subject. To prevent different id's in different environments after running the seeders, I always include the id value in the seeders for picklists like so: public function run(): void { $statusOptions = [ ['id' => 1, 'name' => 'open'], ['id' => 2, 'name' => 'closed'], ]; foreach ($statusOptions as $statusOption) { ItemStatus::create($statusOption); } } Then I use enums or constants in my code much like demonstrated here. Also, I always use the fieldname 'name' for the description in picklists, because that's easy to remember.
In my experience (with Doctrine and EF) ORMs ignore ID value on insert if the field is declared auto increment. Is AI supposed to be toggled off during data seeding like this or is there a better way? $metadata = $this->entityManager->getClassMetaData($className); $metadata->setIdGeneratorType(\Doctrine\ORM\Mapping\ClassMetadata::GENERATOR_TYPE_NONE);
amazing instead of model constants,I started using enums for the role names and add many other methods just to encapsulate related logic. thanks to one of you videos as well
Thanks for the great video. In my projects I never use $user->role->name outside of the User model, I create a model method eg. hasRole(string $role). So in the future if we decided to let the user have multiple roles, the refactor is so easy.
Such hardcoded values get especially complex, when your JS frontent has to be aware of them too (show certain data if value == someConstant, the user should be able to choose on of them in a select, etc..). In a recent project I've written a blade macro to expose my php enums to js, so I don't have to maintain the key,values in both places. Benefit: I now get errors when I try to access invalid keys, so I'm at least aware of the problem and it doesn't fail silently. Where it made sense, I moved the logic to the backend and only exposed the final value/precomputed value as json to the frontend, to avoid using the constants in the frontend in the first place.
In scenarios like these, I typically add an extra column named `type` to the table. Subsequently, I define a global scope in the model to retrieve the corresponding ID of the role by searching via the `type` column. In the model, the scope is defined as follows: ```php public function scopeRiskOfficer($query){ return $query->where('type', 'risk-officer')->first(); } ``` To retrieve the ID of the risk officer role, you can use: ```php Role::riskOfficer()->id; ``
What do you think about putting the ids in the config files in an array key => value(id) with a descriptive key name. In this case broker => 2, so that $user->role_id == config('roles.broker') ?
Thanks for this nice advice, don't seems obvious at begining, and may looks that its more boilerplate code, but in the future you will appreciate. Moreover I think that use a Enums for kind type of data, even prefer than db table, for more consistency in your code. For this particular case i'ld create a RolesEnum file, and there I'll store all roles.
When switching to enums, the question is if you still need the table and records in the database. Except when there are other columns besides id and name of course.
I would still use lookup tables, even if there is enum. To keep data consistent. If i hard delete a value from LU table, having a constrain would prevent it.
I dont agree. This is not just about role_id. But lookups in general. I would rather make sure that IDs are same across environments. They just have to be. ID is not changing, name could. I dont want to compare if strings are matching, but rather IDs. Let say you have stored procedures, db funcions, views, these don't have enums, so you have to hardcode ID. I dont want to use string comparison there. Running imports from excel/running import scripts from DB to DB. IDs have to be same in all environments so I could first test it in QA/staging. I dont want to amend my scripts per env. Having integrations between systems, like sending booking to financtial system, I really dont want to send for example Booking Type = Concert, but ID. Then external system should have same IDs as my system, not necesary same primary key, but foreign key, so they could map it. I dont get it, if someone has different ID per environment, that sounds like junior mistake. At the same time I agree not to hardcode it to 1, 2, 3, etc. in code, but rather use enums/constants, which would be just masked ID. It would make code more readable.
Just FYI, you seem to be getting quieter in every video I watch. Other videos I've watched on this device were fine but at max volume I was struggling to hear you.
Yeah I noticed as well that in this video I was talking more quietly, with less energy. I guess I need to get some sleep more. Or take a few weeks off shooting videos.
@@LaravelDaily you have sounded like you have a cold the last few, but not to the point where the video is a bad lesson. You "sound" fine, I just think your mic levels need adjusting or possibly the mic needs to be closer to you.
@@LaravelDaily I saw that in laravel breeze source and wondered why they are used, I think it's easier to throw exceptions from sub methods rather than return
How about using Caleb Porzio's Sushi package? If you insist on using Eloquent and all its features, if the data in that "table" rarely changes (if ever!) you might as well go for an array "table" using Sushi.
Thank you, very much, your every video increase my knowledge, Keep it up. God bless You.
very nice, i'm demoted to junior
I believe “junior” and “senior” reflect on the experience and quality of the code, not the amount of years you’ve been programming.
Thanks for the intresting subject.
To prevent different id's in different environments after running the seeders, I always include the id value in the seeders for picklists like so:
public function run(): void
{
$statusOptions = [
['id' => 1, 'name' => 'open'],
['id' => 2, 'name' => 'closed'],
];
foreach ($statusOptions as $statusOption) {
ItemStatus::create($statusOption);
}
}
Then I use enums or constants in my code much like demonstrated here. Also, I always use the fieldname 'name' for the description in picklists, because that's easy to remember.
Good approach!
In my experience (with Doctrine and EF) ORMs ignore ID value on insert if the field is declared auto increment. Is AI supposed to be toggled off during data seeding like this or is there a better way?
$metadata = $this->entityManager->getClassMetaData($className);
$metadata->setIdGeneratorType(\Doctrine\ORM\Mapping\ClassMetadata::GENERATOR_TYPE_NONE);
amazing
instead of model constants,I started using enums for the role names and add many other methods just to encapsulate related logic. thanks to one of you videos as well
Thanks for the great video.
In my projects I never use $user->role->name outside of the User model, I create a model method eg. hasRole(string $role).
So in the future if we decided to let the user have multiple roles, the refactor is so easy.
Thank you for this video, I started using Enums recently and it helped me alot
Such hardcoded values get especially complex, when your JS frontent has to be aware of them too (show certain data if value == someConstant, the user should be able to choose on of them in a select, etc..). In a recent project I've written a blade macro to expose my php enums to js, so I don't have to maintain the key,values in both places. Benefit: I now get errors when I try to access invalid keys, so I'm at least aware of the problem and it doesn't fail silently.
Where it made sense, I moved the logic to the backend and only exposed the final value/precomputed value as json to the frontend, to avoid using the constants in the frontend in the first place.
In scenarios like these, I typically add an extra column named `type` to the table. Subsequently, I define a global scope in the model to retrieve the corresponding ID of the role by searching via the `type` column.
In the model, the scope is defined as follows:
```php
public function scopeRiskOfficer($query){
return $query->where('type', 'risk-officer')->first();
}
```
To retrieve the ID of the risk officer role, you can use:
```php
Role::riskOfficer()->id;
``
This is the way.
What do you think about putting the ids in the config files in an array key => value(id) with a descriptive key name. In this case broker => 2, so that $user->role_id == config('roles.broker') ?
Also possible, yes.
Thanks for this nice advice, don't seems obvious at begining, and may looks that its more boilerplate code, but in the future you will appreciate.
Moreover I think that use a Enums for kind type of data, even prefer than db table, for more consistency in your code.
For this particular case i'ld create a RolesEnum file, and there I'll store all roles.
When switching to enums, the question is if you still need the table and records in the database. Except when there are other columns besides id and name of course.
I would still use lookup tables, even if there is enum. To keep data consistent.
If i hard delete a value from LU table, having a constrain would prevent it.
I dont agree. This is not just about role_id. But lookups in general.
I would rather make sure that IDs are same across environments. They just have to be. ID is not changing, name could. I dont want to compare if strings are matching, but rather IDs.
Let say you have stored procedures, db funcions, views, these don't have enums, so you have to hardcode ID. I dont want to use string comparison there.
Running imports from excel/running import scripts from DB to DB. IDs have to be same in all environments so I could first test it in QA/staging. I dont want to amend my scripts per env.
Having integrations between systems, like sending booking to financtial system, I really dont want to send for example Booking Type = Concert, but ID. Then external system should have same IDs as my system, not necesary same primary key, but foreign key, so they could map it.
I dont get it, if someone has different ID per environment, that sounds like junior mistake.
At the same time I agree not to hardcode it to 1, 2, 3, etc. in code, but rather use enums/constants, which would be just masked ID. It would make code more readable.
If you use Filament 3 choose the enum and I think the table roles is useless in this case.
It's not just "protected from future change in the name", it can be as simple as protected from misspelling or string cases, broker instead of Broker
Nice tutorial
Thanks
Thanks! Good code improvements.
I use Enum for that type of issue, it would be better to use const, I think so.
How to select only required columns from db instead of loading all columns in filament tables?
hello. i need to help. my laravel project is working correctly in local. but when i upload my project in prod. cookies not set. i cant solve it
Just FYI, you seem to be getting quieter in every video I watch. Other videos I've watched on this device were fine but at max volume I was struggling to hear you.
Yeah I noticed as well that in this video I was talking more quietly, with less energy.
I guess I need to get some sleep more. Or take a few weeks off shooting videos.
@@LaravelDaily you have sounded like you have a cold the last few, but not to the point where the video is a bad lesson. You "sound" fine, I just think your mic levels need adjusting or possibly the mic needs to be closer to you.
Hi, do you have any video about throwing ValidationException::withMessage and comparing it to back()->withErrors...?
Not specifically about those, no.
@@LaravelDaily I saw that in laravel breeze source and wondered why they are used, I think it's easier to throw exceptions from sub methods rather than return
AWESOME! Always love this channel...
I always use an `alias` column which can't be manually changed in front-end
How about using Caleb Porzio's Sushi package?
If you insist on using Eloquent and all its features, if the data in that "table" rarely changes (if ever!) you might as well go for an array "table" using Sushi.
I never found a real use-case of this, personally, but yes it's an option.
Thanks, good examples 👌🏽
I think in this situation enum is better than this also you can use enum when filter by role it is more readable and maintainable I think
Please which type of browser is that?
I'm using laravel-enum for sample like that
I prefer to do that manually