Closed kironet closed 6 years ago
So, will it solve? When I am using MySQL Workbench, it (doctrine:mapping:import
) is was good for me.
@Ocramius - public properties doesn't solve the problem for relations.
Repetitive code - well yes, we can have a discussion about getters and setters if you want, I'm not much of a fan of the concept, but I would much rather have one concept and use it consistently then mix.
Your call if you don't want to provide functionality anymore. I'm just pointing out that users rely on this functionality and value it.
@BerkhanBerkdemir by moving to other libraries doing that.
@tvogt agree, every developer values quick scaffolding until it is clear that it is just generating legacy code even before the developer has touched it.
If people want to have all their choices made for them, they can move to Laravel.. lol..
Hey there,
I'm adding my 2 cents opinion about this topic. Having a getters/setters generator in Doctrine is really up to @Ocramius and other Doctrine core maintainers. The thing is if this feature is depreciated and doesn't work properly, it should be removed. As Ocramius said you can use public attribute and avoid getters/setters all together, that's how we deal with it in other ORM like SQLAlchemy or in Python in general. By the way, it's been a while I didn't write any PHP/Doctrine/Symfony code, but is it normal that no error is raised when an entity has no getters/setters and all it's attributes are private? Because if I remember well it used to throw an error like "Can't access to attribute" or something like that.
Because if I remember well it used to throw an error like "Can't access to attribute" or something like that.
That must've been a long time ago. These days, Doctrine access your properties using reflection and doesn't care about accessors. If you have used Doctrine entities in combination with the Symfony Form framework, the error may have come from there as the PropertyAccess component used by the form framework indeed requires public accessors for any properties mapped in the form.
Yeah Symfony can't stop using getter and setters, because of forms, etc...
Just now realized I inadvertently closed the issue this morning. After internal discussion, we decided to keep the issue closed: code generation tools have been removed from Doctrine 3.0 and are considered deprecated in the current release; this will not be updated.
If you want to keep using these features, use the MakerBundle.
code generation tools have been removed from Doctrine 3.0 and are considered deprecated in the current release; this will not be updated.
Are XML and YAML configurations also to be deprecated? Most of my projects have the following setup: schema defined in XML and PHP entity files generated based on those XML files. Without the code generation tools, this is going to be a lot more work. The MakerBundle does not seem to be a replacement for this.
Are XML and YAML configurations also to be deprecated?
Yaml mapping is being deprecated, XML and Annotations are staying.
It does not generate the setters and getters.
php bin/console doctrine:generate:entities App:Cars
error:
Can't find base path for "App\Entity\Cars" (path: "/www/crm/src/Entity", destination: "/www/crm/src/Entity").
Someone, please close the comments already ) The feature is gone now.
Hey,
Please update this bundle. I'm trying to generate new entity with this bundle, but I'm getting errors that App or AppBundle does not exist...
commands:
My temporary fix for generating new Entities is:
Create new App class that extends Bundle in src/App.php. Register it in the bundles.php
Unfortunately not working for
php bin/console doctrine:generate:entities App
not generating getters and setters.