DDC-3205: [DX] Interactive Management Command #3990

doctrinebot opened this Issue Jul 5, 2014 · 2 comments

2 participants


Jira issue originally created by user weaverryan:

Hi guys!

This is part of the Symfony Developer Experience Initiative, which I hope can help Doctrine as well :). This is a vision for a console tool to help visualize and manage your Doctrine entities. There are so many options and configuration that I think sometimes either (A) people don't even realize what options are available to them or (B) it's difficult to set everything up correctly (especially with relationships).

Imagine an interactive command that did things like:

  • listed your entities
  • listed fields in your entities (and their options, nullable, unique, etc)
  • Allowed you to change field options (e.g. change a field from nullable true to false
  • Allowed you to see your relationships and change options (cascade, JoinColumn stuff, etc)
  • Allowed you to setup relationships or setup the inverse side of a one-sided relationship
  • Added getters/setters
  • Generated helper methods into repositories (e.g. a method to create a query builder that joins a Product over to ProductImages after creating that relationship).

Does anyone see any issues with this? Obviously, this is HUGE, but it wouldn't need to start huge - it could start simply with some visualization and move from there. I think this could bring down the barrier to entry tremendously, and offer (via generation and visualization) some of the benefits of AR magic without that darn magic :).



Comment created by @ocramius:

TL;DR: dumping details, yes please! modifying files/mappings, no-go.

A couple of things here:

  • listing entities is already available, see orm:info
  • listing all fields and additional details may be useful as an addition to orm:info via a flag. Implementation is also trivial
  • changing mappings via CLI - I'm really against this proposal. I've already tried getting rid of anything codegen-related from the symfony documentation, and I would not want codegen to land in the ORM. Mappings may come from annotations, from xml configs, from yaml or plain PHP files. They may also be processed by listeners and look completely different from the file counterparts. No, let's stay away from any ORM-driven mapping modification.
  • adding getters/setters, generating repositories, adding fields/associations: Doctrine's codegen is actually ONLY meant to provide an easy migration from a legacy DB to ORM entities+mappings, and we're also trying to get away from it in core.

Note that for mappings there's http://www.pulpo18.com/, which eases the path for newcomers. I also developed something for the ZF2 packages (which I must move to a separate library), see http://stackoverflow.com/a/14574952/347063

@beberlei beberlei was assigned by doctrinebot Dec 6, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment