Skip to content
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

[RFC] Migrate doctrine:generate:entity logic to make:entity #83

Closed
gabiudrescu opened this issue Dec 3, 2017 · 30 comments
Closed

[RFC] Migrate doctrine:generate:entity logic to make:entity #83

gabiudrescu opened this issue Dec 3, 2017 · 30 comments
Labels
Feature New Feature RFC

Comments

@gabiudrescu
Copy link

For me, one of the first downsides I have encountered while testing out Flex with Symfony4 is the missing command of doctrine:generate:entity with all the helper questions + the not working doctrine:generate:entities (see doctrine/DoctrineBundle#729 fore more info).

My previous workflow whenever I was prototyping something was:

  • generate the entities with doctrine:generate:entity by answering to a couple of questions;
  • I always opted for YAML mapping, so the next step was to edit the files to create the relations between entities
  • updating the entities with doctrine:generate:entities to get the new properties and appropriate methods (e.g. __construct with initialized ArrayCollection objects, addElement, removeElement etc.)
  • update schema

With the current make:entity command, it took me more than 4 times the time in order to get an up & running 3 entities related between them (Job, Category, Affiliate - remember good ol' Jobeet tutorial).

I would like to bring under your attention the need of migrating the functionality from SensioGeneratorBundle to the MakerBundle for doctrine:generate:entity command (very useful when first creating an entity).

Also, I would like to propose discussing the idea of migrating doctrine:generate:entities from DoctrineBundle, as the core maintainers from that project are not in favor of maintaining this command for the purpose of generating setters and getters based on mapping information.

I don't know if the 2nd proposal should be part of make:entity command or another one command.

@javiereguiluz
Copy link
Member

I agree completely. Creating an interactive make:entity was on our TODO list since day one. For the first version of the bundle we didn't want to include interactive commands, but we're working on this.

@gabiudrescu
Copy link
Author

@javiereguiluz that's an awesome news! I find those interactive commands very helpful and allow me to be very productive. hope I'm not the only one using / asking for them :)

how about the other idea: taking the responsibility of doctrine:generate:entities from DoctrineBundle to MakerBundle for generating entities based on existing mapping (yml, xml or even annotations)?

@javiereguiluz
Copy link
Member

I don't know what to say about your second question. We'll need to think about it.

@weaverryan
Copy link
Member

The trick will be to try to not create too many questions. The old command suffered from usability problems: people would make a typo 10 questions in and not be able to recover. That’s the challenge.

I would also like to support relations ships. And I would like to generate getters + setters: that’s especially useful because we can generate really awesome add/remover methods for relationships that synchronize the inverse side.

@Gregwar
Copy link

Gregwar commented Dec 4, 2017

I am currently using Symfony flex and not having entities available to generate accessors is really troublesome in the workflow.

@fredpo
Copy link

fredpo commented Dec 6, 2017

@gabiudrescu
I use the same chain for prototyping and bootstrapping a project. This whole Flex move is completely pointless without an efficient way to generate Entities, which is time consuming and is a stumbling block when you just want an API up and running quickly.

I'm glad to see this issue getting attention.

@Reflex14
Copy link

I was searching for this, because I could not believe it was gone. Happy to see there is an issue, confirming this.

We are on the start of a new project and putting ideas directly into your project, this fast, is the most fun part of any project. And I don't care if I made a typo in the process, most of the time I'll continue and fix it later on.

Right now I'm stubborn and will continue using SF4 but I have a SF3.3 project alongside to generate my orm and entities 🤣

@LinkingYou
Copy link

The official symfony documentation (3.4 / 4.0) describes that you can use other formats instead of annotations ( https://symfony.com/doc/current/doctrine.html ).

It also works as described - Symfony gets the needed database / table info from the configured YML file.

But it does not make sense if I should write the YML files in the future and then create the appropriate entity class by hand.

I would also be very happy if the new Maker Bundle can also create and update the appropriate Entity classes from Yml files. I also love annotations elsewhere - but with entities, working with yml files is much faster and easier.

@stof
Copy link
Member

stof commented Dec 13, 2017

The other thing to remember is that the SensioGeneratorBundle command was relying on the Doctrine ORM EntityGenerator, which is not actively maintained and is actively recommended against using it by the Doctrine ORM team.

@zoop1984
Copy link

zoop1984 commented Dec 20, 2017

Glad to see that it isn't just me. I've been searching for it everywhere. Might want to take a look at the docs page at https://symfony.com/doc/current/doctrine.html
It first talks about how to generate an entity, then about how to expand fields (including xml/yml examples) and then "The Product class is fully-configured and ready to save to a product table.", thats plainly not true, the steps above it don't update the product class at all and thus the migrations stuff afterwards fails. The example only works if you use annotations, since you'll be defining the field variables at the same time (and afterwards, no other xml/yml examples are given anymore, its all about those horrible annotations).

The main selling point for Symfony always was for us how it can take work away from you, not having to worry to perfectly create object classes, just define your fields and Symfony does the rest. Never believed in annotations but luckily there were always alternate options. But now, we need to do everything manually. Work that previously took seconds, now takes minutes. Time to switch back to Symfony 3.x, in our opinion, Symfony 4 simply isn't production ready yet.

@pascalwacker
Copy link

Is there an ETA on an improved make:entity command? And will there be a replacement to generate getter/setter? Sure IDE like PHPStrom can do it too, but I'd still prefer a console command for it.

@weaverryan
Copy link
Member

In working on the make:entity improvements right now. I could have a PR as early as this weekend :)

@gabiudrescu
Copy link
Author

@weaverryan that's awesome news! Santa is coming early this year :D

@gabiudrescu
Copy link
Author

Can't hardly wait to beta test this

@weaverryan
Copy link
Member

Haha, perfect! Because it will need some testing ;).

@javiereguiluz javiereguiluz added RFC Feature New Feature labels Jan 24, 2018
@nkl90
Copy link

nkl90 commented Feb 7, 2018

I do not understand one thing, why not modernized SensioGeneratorBundle for SF4 Flex? Why this bicycle?

@javiereguiluz
Copy link
Member

@nkl90 we thought about that ... but the effort to modernize/refactor GeneratorBundle would be bigger than creating MakerBundle from scratch and the result would be worse.

@fredpo
Copy link

fredpo commented Feb 7, 2018

@nkl90 If you check doctrine/DoctrineBundle#729, you will find that Doctrine no longer supports generation. Even though it's a very popular feature the maintainers decide that they will no longer generate entities, getters and setters because it makes it too easy for people to develop and creates "anemic entities," as if no one edits them afterwards.

I found the whole thread very childish and the Doctrine maintainers to be very arrogant and narrow minded. So I guess we have to have a Symfony solution and not rely on Doctrine.

At the moment I'm forced to generate in Symfony 3.3 and copy over to Symfony 4. It's really annoying, especially when using API Platform, which relies on generation for a streamlined process.

Honestly, who wants to sit there and grind through creating entities, getters and setters. Design DB, generate, customize, done.

@nkl90
Copy link

nkl90 commented Feb 8, 2018

@fredpo, I've been doing this all my life: Design DB, generate, customize, done. But Doctinre has taught me not to think about the DBMS in the development process. And now I have to retrain. This is bullshit!

@weaverryan
Copy link
Member

If you want to test the new command, see #104. It does everything the old commands did, and more :).

The doctrine:generate:entities equivalent is “make:entity --regenerate”

@fredpo
Copy link

fredpo commented Feb 9, 2018

@weaverryan That's awesome and works great for small projects. Now if only it generated all that from a database. Going through an interactive generator for 200+ fields with 40+ relations is not an efficient use of time.

@weaverryan
Copy link
Member

@fredpo - that part is a separate issue. We do still need to update DoctrineBundle so the reverse engineering stuff works without a bundle. I don’t think the doctrine devs are against that, and I think it should be fairly simple - I haven’t looked at it yet. Once you’ve reverse engineered to, for example, XML, you can use the make:entity command to generate all your classes.

For your project, just create a bundle temporarily so you can do the reverse engineer step.

@fredpo
Copy link

fredpo commented Feb 9, 2018

@weaverryan Great to hear that you're on it 👍

just create a bundle temporarily so you can do the reverse engineer step

That's the current process, unfortunately.

@nkl90
Copy link

nkl90 commented Feb 13, 2018

@fredpo, not always data stored in single source. Sometimes it happens data stored in many source (REST API, SOAP, SQL, NoSQL and etc.). For such case this soulitions (fast prototyping data models via console command) it was coined.

@safwan74
Copy link

When I type php bin/console make:entity, I don't get the interactive tool with it. It just creates the class without giving me the chance to enter the properties "Fields"

@gabiudrescu
Copy link
Author

What about __toString() methods?

what do you think about adding a question to ask the developer if there should be a __toString() method in that entity?

ideally, the developer should be able to specify a string field that can be used for retrieval on this magic method call.

@gabiudrescu
Copy link
Author

have you tried this command to generate a Category tree?

basically, a one to many self referencing.

@safwan74
Copy link

Gabiudrescu, it is exactly what I was working on, a Category, one to many self referencing. luckily the doctrine documentation is straight forward and exact match for my requirements. However, I really miss the standard edition in my latest project. It was so easy to generate the skeleton of the entity, and then I carry on working on the associations manually. It is a lot of pain if you have an entity with many properties and you have to type them manually or copy and paste and imagine if you have so many entities. I guess as a community we will have to solve this lack of generator tools in flex. I like flex a lot and it is a step in the right direction but the awesomeness of Symfony comes from these tools. I understand that flex is optional in 3.4 and even in 4. I like the structure and the bundle-less approach, it will be even greater with the maker bundle if all the generation tools are maturing enough.

@weaverryan
Copy link
Member

See #104 :). An even better version of the command is coming.

@IndraGunawan
Copy link
Contributor

IndraGunawan commented Mar 21, 2018

i guess we can close this issue because v1.3.0 has been released

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature New Feature RFC
Projects
None yet
Development

No branches or pull requests