-
-
Notifications
You must be signed in to change notification settings - Fork 412
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[make:entity] Property types, Types:: constant & type guessing #1147
[make:entity] Property types, Types:: constant & type guessing #1147
Conversation
Also dropping the Column(type:) argument when it can be inferred from the property type.
This is ready! The Symfony 6.2.x-dev failures are from an upstream bug - symfony/symfony#46916 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shweet! Couple of minor comments...
[Mapping::class => 'ORM'], | ||
['Doctrine\\ORM\\Mapping' => 'ORM'], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this for code readability?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome Work! Thanks @Geekimo && @weaverryan
Thanks @weaverryan for updating my work ! |
@Geekimo @weaverryan first off, nice work! I noticed this PR explicitely adds |
@icedevelopment Hello, thanks. |
phpstan now always flags the properties as incorrect, because the database says 'not null' and the PHP code says 'nullable'. I know that you can't access an uninitialized property, but forcing it to null... is that right? We've worked for years with non-nullable properties this way. You set them in the constructor if you want safe, or other coding standards.. I'm now in doubt if I need to ignore the errors in phpstan, or adjust the scaffolding from make:entity to make the nullable types match the database layout. Maybe from my C/C++ background, but an uninitialized property (and the dangers of it :P) sound perfectly fine in my head :). |
…ntity output (alamirault) This PR was merged into the 5.4 branch. Discussion ---------- [Doctrine] Update example to match actual make::entity output From slack ![image](https://user-images.githubusercontent.com/9253091/215199944-ecc4544f-62c8-435d-928d-e219b1c5e732.png) It's a new behavior since maker 1.44.0 released July 26th, 2022 symfony/maker-bundle#1147 (New example is based on local execution) Commits ------- 32d50e9 Update example to match actual make::entity output
Hi!
This expands on the excellent work in #1039. This adds to
make:entity
:A) Property types - e.g.
private ?int $id = null
. Most property types are nullable and default to null, effectively making them typed, but identical to how things worked before (before types, properties were naturally nullable and defaulted to null).B) Removes most
type:
options inORM\Column
as these are now "guessed" since doctrine/orm 2.9 from the property types.C) For the few
type:
options that remain, we use aTypes::
constant.Cheers!