I have the same issue when executing doctrine:mapping:import, since symfony4 is bundle-less there is no destination bundle to specify.

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...

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 doctrine:mapping:import (though imperfect by design because it's doing an impossible task) is used by a lot of developers.

The problem exists in 3.4 too when using flex.
Trying to generate getters and setters with command failed
A way to fix it in #723

@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;
    }

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..
My way to (hope) temporary fix it:

1. create a symfony 3.3 installation
2. doctrine:mapping:import from existing database
3. copy and paste Entity files in my new symfony 4 project (after change "AppBundle" with "App" in each one)
4. doctrine:schema:update --force in new symfony 4 project

@molven04, @kporras07 You can use Symfony Maker: https://symfony.com/doc/current/bundles/SymfonyMakerBundle/index.html

My 5 cents:

• actually, generators are Rails - style legacy. Don't trust autogenerated code, unless you don't see it (like container)
• still current generator works bad when adding $blabla = new ArrayCollection in constructor
• any recent IDE (including de-facto PHPStrom) can generate fluid getters and setters for you faster and in more controlled way than Doctrine does

@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.

Yeah, I was using command doctrine:generate:entities only because of relationships. It was easy and fast.

you can use a text editor plugin to generate the setters and getters
for exmaple

https://github.com/francodacosta/atom-php-getters-setters

Thanx @martinezvictor84

https://github.com/francodacosta/atom-php-getters-setters
https://atom.io/packages/php-getters-setters

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...

Yes it can: https://webmozart.io/blog/2015/09/09/value-objects-in-symfony-forms/

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?

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.