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
Symfony Flex - Generating entity #729
Comments
I have the same issue when executing |
Well, none of the Doctrine maintainers is in favor of using these generation commands (they tend to create more harm than good in most cases). So I suspect this is the reason why they were not spotted as broken in a Flex context yet (none of the Symfony or Doctrine maintainers trying Flex early were using them) |
Well, thats nice(I don't see what harm can generating entity cause), at this point I don't see why I should stay with Symfony, I can just switch to Laravel, if since flex it looks like I will have to do everything manually... |
The harm is getting a totally anemic domain model that reflects the RDBMS.
At that point, just use the RDBMS instead, as the ORM is probably a bad fit.
The fact that you use the generator means that you aren't designing any of
your entities, which means that they will also be useless at runtime, if
not a hindrance.
On 4 Nov 2017 11:45, "kironet" <notifications@github.com> wrote:
Thats nice(I don't see what harm can generating entity cause), at this
point I don't see why I should stay with Symfony, I can just switch to
Laravel, if since flex I have to do everything manually...
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#729 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAJakL9efzAHS0rwo-nMOI2OvPoweBycks5szEBTgaJpZM4QQmr3>
.
|
We will support the generation commands, but in a different bundle... so stay tuned :). Remember, Symfony 4 isn't even out yet - we're still (and will continue) polish things. But, thanks for the issue! In DoctrineBundle, I think we should deprecate any commands that you don't want to support. However, I know the |
The problem exists in 3.4 too when using flex. |
@stof, so you basically offer to use public properties for doctrine? |
Hi all! DisconnectedMetadataFactory not suitable for Symfony 4 also For example, doesn't work for PSR-4: /**
* Get a base path for a class
*
* @param string $name class name
* @param string $namespace class namespace
* @param string $path class path
*
* @return string
* @throws \RuntimeException When base path not found
*/
private function getBasePathForClass($name, $namespace, $path)
{
$namespace = str_replace('\\', '/', $namespace);
$search = str_replace('\\', '/', $path);
$destination = str_replace('/'.$namespace, '', $search, $c);
if ($c != 1) {
throw new \RuntimeException(sprintf('Can\'t find base path for "%s" (path: "%s", destination: "%s").', $name, $path, $destination));
}
return $destination;
} |
The generators assume a PSR-0 structure by design: that is an intentional
decision.
…On 25 Nov 2017 12:03, "Sergey Pantushin" ***@***.***> wrote:
Hi all! DisconnectedMetadataFactory not suitable for Symfony 4 also
For example, doesn't work for PSR-4:
/** * Get a base path for a class * * @param string $name class name * @param string $namespace class namespace * @param string $path class path * * @return string * @throws \RuntimeException When base path not found */ private function getBasePathForClass($name, $namespace, $path) { $namespace = str_replace('\\', '/', $namespace); $search = str_replace('\\', '/', $path); $destination = str_replace('/'.$namespace, '', $search, $c); if ($c != 1) { throw new \RuntimeException(sprintf('Can\'t find base path for "%s" (path: "%s", destination: "%s").', $name, $path, $destination)); } return $destination; }
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#729 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAJakEpVG_4REUWHOIP3FC317bBPd6uIks5s5_PxgaJpZM4QQmr3>
.
|
Yes. I see. We can find out path from /** @var Composer\Autoload\ClassLoader $loader */
$loader = require __DIR__.'/../vendor/autoload.php';
$loader->getPrefixesPsr4(); This is the place for a little magic)) |
Hi @weaverryan any news on this? I'm still getting the same error reported in #723 with Symfony 4 |
Hi all! I have the same issue..
|
@molven04, @kporras07 You can use Symfony Maker: https://symfony.com/doc/current/bundles/SymfonyMakerBundle/index.html |
@Ocramius But Symfony is used by a wide range of shops, we cannot assume that the author of the mapping is the developer and suggest they just write the mapping in annotations to begin with (you did not say that but that argument is frequently raised). |
In 5 years of answering ORM questions, I can assume that.
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
…On Sun, Dec 3, 2017 at 7:38 AM, Saidou GUEYE ***@***.***> wrote:
@Ocramius <https://github.com/ocramius>
I would agree with you on doctrine:mapping:import. Four to 5 years ago I
used it when migrating existing applications to Symfony 2. I stopped using
it because it required so much work to fix the generated mappings that
writing the mappings from scratch was more efficient.
But `doctrine:generate:entities' is very useful and does not lead to
anemic data model. I use it to generate entity classes from YAML or XML
mapping and it does not cause any harm. It really shines in this use case
as it handles all the boring, repetitive and error prone process of
converting XML or YAML mapping into entity classes.
Symfony is used by a wide range of shops, we cannot assume that the author
of the mapping is the developer and suggest they just write the mapping in
annotations to begin with (you did not say that but that argument is
frequently raised).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#729 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAJakOlllLj3bjjwKJmwDPbZbUo-Jy6Iks5s8kH2gaJpZM4QQmr3>
.
|
I know that using pre-Symfony 4 as a developer, you answered a few basic questions that were prompted on the screen and everything was created on your behalf. no more of similar code written by hand over and over again... and coupled with an EasyAdmin with low customization, it provided out of the box functionality by using basically only config files. you could have an up and running PoC application in 30 minutes, having the rest of the time for doing the real coding for the more relevant business layer. |
My 5 cents:
|
@andrewtch I haven't been able to make PHPStorm generate methods for collections properties (addElement, removeElement + constructor initialization). hence, relied on the generator to do this instead of me. |
to generate entities of tables in symfony 4, try it:
|
Yeah, I was using command |
you can use a text editor plugin to generate the setters and getters |
@martinezvictor84 For simple getters and setters you can just use phpstorm |
@martinezvictor84 With Phpstorm, when you are in an inversed entity, Generate Getters & Setters doesn't work properly, cause it does'nt generate the 'add'/'remove' methods |
Just a heads-up here: support for codegen tools, including EntityGenerator, EntityRepositoryGenerator, orm:generate:entities, orm:generate-repositories and doctrine:convert-mapping, has been dropped and they will not be part of Doctrine 3.0 (ref doctrine/orm#6870). |
Woohoo let's spend weeks just by writing entities from scratch. 👍 |
@Majkl578 You said: "It'd be awesome if Symfony started phasing them out, the sooner the better, and teach its users good manners - i.e. how to write entities properly, not by generating anemic 1:1 table copy." So lets consider simple example to prove you are wrong: Now I am struggling with import of several GB of data to more than 100 tables. All data must be imported with little reorganization of relation names etc... I created my new database scheme with MysqlWorkbench - fastest way. Please tell me who is going to pay for time I will be wasting on writing everything from scratch? It will take me about one 10 days to do all the job. I think that you forget that writing applications isn't always a hobby when you have infinite time and you can spent to concerning good manners only. After my import will be done I am going use DDD to write my target application where persistent layer will be complete decoupled from domain. But for now my client wont allow me to just skip import of some data because lack of time or because you don't like it. You can't put all people to one bag and say that they need to be more educated. If you don't like generation entities inside doctrine3 project just move it and maintain it in separate branch or project but don't kill feature that my be really helpful for many people. If you're unable understand it I hope there will people that will do and will have 10000 of stars on github with new generator project! |
You are importing an entire schema without changing anything, yet you had to do design the new schema manually in MySQL Workbench? I cannot see where this could possibly go wrong! Jokes apart, you will likely incur in:
Importing the entire schema into a "new" application without inspecting manually each scenario and each business rule that couldn't be coded into a DB-level constraint is gonna be more trouble. You will hit issues, you will corrupt the data and the migration will just lead to misunderstanding by consumers of the generated model. I've gone through the same scenario you described above multiple times, and it is generally a waste of money to abstract away existing data models, since you do not know everything that the existing data model is supposed to do.
Then you likely don't need Doctrine ORM: you probably want a Table-Data-Gateway or an Active-Record implementation, or even something more lightweight than that if applicable. You'd just end up writing something quite complex that:
This train has left the station over 2 years ago, and it is just going to happen now. We're not in a popularity contest here: if people like shooting themselves in the foot, so be it, but we'll provide as little assistance (before AND after) as possible to focus on more relevant problems. To recap:
|
http://docs.doctrine-project.org/en/latest/tutorials/getting-started.html
|
I disagree. I am importing data from different source types (not just doing copy of existing schema):
Ok, You may say that Doctrine is not tool designed as a some kind of tool/helper to import data from junk sources like those i have ..and I agree with that, I also agree and understand why removing generators will prevent people of saying "ORM sucks" because they put whole database to it. But you must admit that there are scenarios when generator can be useful. Maybe there is some approach to kill to birds with one stone and save generators for cases like mine and also save people from abusing it. Thanks for answer |
Precisely the opposite, which is why they are being removed here. |
Just want to say this that for me this is "Volstead Act" approach like in USA in 1919. Instead of educating people you just want to put all people to the same bag and ban all generators, its exactly like prohibition did with alkohol in United States. |
No prohibition: make your own generator. Prohibition is when I lock the thread, which is really close. As for the docs: doctrine/orm#6902 |
Perhaps consider who's paying the maintainers of this project to do your job for you? |
Guys, I've experienced First I was like:
Then I was:
And after the first year:
And today, it's more than four years after the birth of this "V2" project. Still not on production (it's a personal project so I don't mind, in the beginning it was just for fun), and by the way it's the same for all other non-personal projects on which I used these features:
The same goes for Even though my entities are still a mix between anemic and rich, I tend to think every model should be rich, so no setters, but getters are fine. That's why I created doctrine/orm#6902 and will take time in the next weeks to update it, unless someone more clever than me wants to participate. And that's also why I agree on the fact that That's my 2 cents |
So here are my 2 cents to this discussion. Is it really doctrine or symfony task to teach people DDD, i think so. Doctrine is only one tool to practice DDD. You can also use eloquent, propelorm or just dbal to do it. Should each of this project do document DDD? And for all people who want to have this feature: I see many comments here, but no one extract this feature into his own library bundle. You can also create a PR and say "Hey i want to maintain this feature". Then this is how open source should work. The guys form doctrine do a great job and instead of blame this people they do bad work, think about this: How many time (and money) do you save with doctrine and you pay nothing for it. See this as a chance to give them something back and be constructive. |
There's no need to discuss about this :) Doctrine maintainers have removed all the generator tools because they think it's the best for their project ... and we're working on adding new and modern generator tools to Symfony's Maker bundle because we think it's the best for Symfony. So we both get what we want, nobody is "doing it wrong", everybody should be happy ... and there's no need to discuss about this. Cheers! |
"Perhaps consider who's paying the maintainers of this project to do your job for you?" @javiereguiluz You right! @Ocramius After reading whole discussion I admit that generators inside doctrine project are bad idea and their are causing to many problems and most of my arguments I wrote earlier sucks! :) |
I never used this tool after pass 2-3 months in Doctrine, try to go RDBMS and some IDE like Phpstorm so now about 5+ years life is easy. |
Half of you are insane, right? Don't tell me how to write my code. If I want all my entities to have getters and setters for all their variables, and access to the very convenient relation add, remove, etc. methods then I want it and it's not your place to tell me what I want. Symfony used to be perfect for banging out a quick prototype exactly because of this. Especially if you use XML or Yaml for entity mapping, the getter/setter code generation is a gift from heaven. I just started a new project on Flex, after using Symfony 2 and 3 for older ones, and the missing entity generator is the reason I'm shelving it for the weekend until I figure out how to proceed without wasting hours on writing extremely repetitive code. |
Just make properties public and you have the same behaviour: no need for generators or "extremely repetitive code" (which is quite the code smell again, and leads to extremely repetitive maintenance work). We're not telling you how to write your code, we just stop writing code for you. |
So, will it solve? When I am using MySQL Workbench, it ( |
@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. |
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. |
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. |
Yaml mapping is being deprecated, XML and Annotations are staying. |
It does not generate the setters and getters.
error:
|
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.The text was updated successfully, but these errors were encountered: