How to generate entities from database view with doctrine and symfony2

Now you create your orm files only. You need to follow 2 more steps. I will give you the complete steps from begining.

Before doing this delete all yml files in your orm directory that you had created early.

I hope MyHomeBundle is your bundle name

1).php app/console doctrine:mapping:convert yml ./src/My/HomeBundle/Resources/config/doctrine --from-database --force 

  Symfony2 generate entity from Database

 2).php app/console doctrine:mapping:import MyHomeBundle yml

 3).php app/console doctrine:generate:entities MyHomeBundle

Hope this helps you.

Got the same issue, i use xml instead of yml but must be the same.

Check in your orm entity if the name include the correct route, exemple:

<entity name="Myapp\MyrBundle\Entity\MyEntity" table="myentity">

Because when i generate my orm from database the name was like that:

<entity name="MyEntity" table="myentity">

So doctrine didn't understand the right path.

Hope i'm clear and this will help you!

I know it's an old question but I found the trick (Symfony 6) to generate entities from SQL view (I use a SQL server database).

So I modified two methods of the SQLServerPlatform.php file of the doctrine bundle.

public function getListTablesSQL()
{
    // "sysdiagrams" table must be ignored as it's internal SQL Server table for Database Diagrams
    // Category 2 must be ignored as it is "MS SQL Server 'pseudo-system' object[s]" for replication
    return 'SELECT name, SCHEMA_NAME (uid) AS schema_name FROM sysobjects'
        . " WHERE type = 'V' AND name != 'sysdiagrams' AND category != 2 ORDER BY name";
}

I changed the where condition parameter 'U' by 'V' for view.

Same operation for the method getListTableColumnsSQL(), we change here the 'U' parameter of the where condition by 'V'.

public function getListTableColumnsSQL($table, $database = null)
{

    return "SELECT    col.name,
                      type.name AS type,
                      col.max_length AS length,
                      ~col.is_nullable AS notnull,
                      def.definition AS [default],
                      col.scale,
                      col.precision,
                      col.is_identity AS autoincrement,
                      col.collation_name AS collation,
                      CAST(prop.value AS NVARCHAR(MAX)) AS comment -- CAST avoids driver error for sql_variant type
            FROM      sys.columns AS col
            JOIN      sys.types AS type
            ON        col.user_type_id = type.user_type_id
            JOIN      sys.objects AS obj
            ON        col.object_id = obj.object_id
            JOIN      sys.schemas AS scm
            ON        obj.schema_id = scm.schema_id
            LEFT JOIN sys.default_constraints def
            ON        col.default_object_id = def.object_id
            AND       col.object_id = def.parent_object_id
            LEFT JOIN sys.extended_properties AS prop
            ON        obj.object_id = prop.major_id
            AND       col.column_id = prop.minor_id
            AND       prop.name = 'MS_Description'
            WHERE     obj.type = 'V'
            AND       " . $this->getTableWhereClause($table, 'scm.name', 'obj.name');
}

Maybe this will help someone.

As you can see here: http://symfony.com/doc/current/cookbook/doctrine/reverse_engineering.html the reverse engineering process from db to entity is not fully implemented yet:

"As the Doctrine tools documentation says, reverse engineering is a one-time process to get started on a project. Doctrine is able to convert approximately 70-80% of the necessary mapping information based on fields, indexes and foreign key constraints. Doctrine can't discover inverse associations, inheritance types, entities with foreign keys as primary keys or semantical operations on associations such as cascade or lifecycle events. Some additional work on the generated entities will be necessary afterwards to design each to fit your domain model specificities."