Automatically generating forms and tables | doctrine/dbal
Sometimes this command generate the form and table data. But most of the time it's not work. I installed the package and give protected_fillable data to model, but it's still not working.
What should I do to find the problem?
Why this command not generating the data automatically?
Solution:Jump to solution
yes, the generator looks at the DB table, not Model. so make sure to run migration before
filament:resource --generate
, you can add --force
flag to replace the generated resource12 Replies
Did you build out the model first?
Yes
This is my Gallery Model.
If I run the command
It's create this GalleryResource
Where form schema and table columns is empty.
@toeknee Can you help me to solve this?
Please read the #✅┊rules and don't tag people unless they have asked you too or you are friends.
What is your table structure? Are you using ENUMS?
No, I don't have enums.
Then I am unsure sorry.
Is the model in: app\Models
Yes! it's app\Models
I'm sorry about that. I was think that you don't get my reply notifications, that's why I tagged you. I'm sorry for tag you.
We are not paid support, so if we don't get the notification that's fine. We will get round to it when we can.
That's fine. You can ignore it.
@Abdur Razzaque How do you define the
status
column in the database? Can you show the migration for that table/column?
Also, do you get an error or does it just fail?I see that you've created your Model file with the
$fillable
array, but have you also created your migration file and run it against your local database?
I can't find documentation on this, so I very well might be misremembering, but I feel like I remember reading/learning that the resource generator looks at the DB table to attempt to figure out the form field types, not at the Model.Solution
yes, the generator looks at the DB table, not Model. so make sure to run migration before
filament:resource --generate
, you can add --force
flag to replace the generated resourceI've already resolved my issue, but I wasn't aware of the logical cause of the database table. I thought the command worked through the model. This command functions properly after executing the migration command, i.e,