0

I would like to add a database table to an existing bundle.

But currently i can't find a way to integrate it into the DoctrineMigration process without a fixed coupling.

I have installed "doctrine/doctrine-migrations-bundle": "^2.2" but then I get the error message: Maximum one migration path can be specified with the 2.x version.

Currently I have solved it with a command which uses Doctine to create and update the table. 

//Example
$schema = new Schema();
$entryTable = $schema->createTable($this->getTableName());
$entryTable->addColumn(
    'id',
    'integer',
    [
        'unsigned' => true,
        'autoincrement' => true
    ]
);
$entryTable->addColumn(
    'col1',
    'string',
    [
        'length' => 255,
        'notNull' => true
    ]
);
$entryTable->addColumn(
    'col2',
    'string',
    [
        'length' => 255,
        'notNull' => true
    ]
);
$entryTable->setPrimaryKey(array('id'));

$queries = $schema->toSql($this->databaseConnection->getDatabasePlatform());
$this->databaseConnection->query($queries);

Is there a smarter way?

Best regards,

André

Hans FooBar
  • 149
  • 11
  • I wouldn't like bundles adding migrations. I would assume this really is somewhat of an edge case... Your way already seems somewhat smart, really depends on how this is used and by whom, and if this behavior is expected ... – Jakumi May 23 '20 at 19:43
  • 1
    I think same as @Jakumi. Normally, this shouldn't be in a bundle. I would like to get an Interface from you Bundle for the persisted entity which i can implement on my own and also create the needed Migrations on my own. – Samuel Breu May 23 '20 at 20:37
  • @Jakumi I'm not so sure it's wise either.Since Doctrine 3.0 it is possible to configure multiple migration folders. If you uninstall the bundle, there will be conflicts in the migration, I think. – Hans FooBar May 23 '20 at 23:09
  • @SamuelBreu I think this is a good hint with the interface. – Hans FooBar May 23 '20 at 23:10
  • instead of an interface, an extendable class (in doctrine: [mapped superclass](https://www.doctrine-project.org/projects/doctrine-orm/en/2.7/reference/inheritance-mapping.html#inheritance-mapping)) or [embeddable](https://www.doctrine-project.org/projects/doctrine-orm/en/2.7/tutorials/embeddables.html) might be a better fit and is imho easier to use. it's still hard to communicate changes to the "base" entity to the user of the package (i.e. another developer), maybe those mapped superclasses/embeddables should even have a version number in their name or trigger a new major version? – Jakumi May 24 '20 at 00:26
  • Im pretty sure an Interface would fit perfect for that, and its also common to do eg. deprecation hints on Interfaces which will inform the using developer about changes/deprecations and that would work perfect as long the package owner follows some release intervals. – Samuel Breu May 25 '20 at 00:14

0 Answers0