[DMIG-25] migrating muliple databases Created: 28/Jul/11 Updated: 17/Mar/12 Resolved: 17/Mar/12 |
|
| Status: | Resolved |
| Project: | Doctrine Migrations |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Critical |
| Reporter: | Ajinder Singh | Assignee: | Benjamin Eberlei |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Environment: |
symfony2 |
||
| Description |
|
I have 2 databases db1 and db2 in symfony2 + doctrine2 and both databases are different from each other in terms of tables and their fields. |
| Comments |
| Comment by Benjamin Eberlei [ 17/Mar/12 ] |
|
This is not supported, Migrations works for exactly one database, not more. |
[DMIG-31] $table->renameColumn() actually drops the column Created: 23/Dec/11 Updated: 19/Jun/12 Resolved: 04/Jun/12 |
|
| Status: | Resolved |
| Project: | Doctrine Migrations |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Critical |
| Reporter: | Nikola Petkanski | Assignee: | Benjamin Eberlei |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Environment: |
symfony 2.0.7 |
||
| Description |
|
Tried to use renameColumn() into one of my migration scripts and it dropped the table. The code does not seem okay as well: namespace Doctrine\DBAL\Schema;
..
class Table extends AbstractAsset
{
..
/**
* Rename Column
*
* @param string $oldColumnName
* @param string $newColumnName
* @return Table
*/
public function renameColumn($oldColumnName, $newColumnName)
{
$column = $this->getColumn($oldColumnName);
$this->dropColumn($oldColumnName);
$column->_setName($newColumnName);
return $this;
}
..
|
| Comments |
| Comment by Tyler Sommer [ 06/Feb/12 ] |
|
Doctrine\DBAL\Schema\Table is actually not a part of Doctrine Migrations, rather just the Database Abstraction Layer project. Recommend this gets sorted as such. |
| Comment by David Buchmann [ 04/Jun/12 ] |
|
this is a duplicate of any chances of getting the issue fixed? |
| Comment by Benjamin Eberlei [ 04/Jun/12 ] |
|
From the internals this is really complicated. I will delete the method instead. |
| Comment by Gonzalo Sainz-Trapaga [ 19/Jun/12 ] |
|
Does this mean Doctrine Migrations won't support renaming columns? I'm sorry but the alternative of not supporting it at all doesn't really work. It's a basic operation for DB schema changes, which are the whole point of migrations. What exactly is the proble? I have seen the algorithms for inferring that a column or table should be renamed and they are pretty simplistic. Maybe the solution is adding some sort of hinting to the renameX operations so that there is metadata inside the Table Schemas saying what the original columns or tables were. Thoughts? |
[DMIG-15] Drop not null is not working in Postgres Created: 16/Nov/10 Updated: 16/Nov/10 Resolved: 16/Nov/10 |
|
| Status: | Resolved |
| Project: | Doctrine Migrations |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Lea Haensenberger | Assignee: | Jonathan H. Wage |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Environment: |
Postgresql 8.4, Symfony 1.4, Doctrine 1.2 |
||
| Description |
|
When removing the not null from a column the migration does not change anything in the database. This is due to the following check on line 162 of lib/vendor/symfony/lib/plugins/sfDoctrinePlugin/lib/vendor/doctrine/Doctrine/Export/Pgsql.php if ( ! empty($field['definition']['notnull'])) So if notnull is not there or set to false or '0' or 0 the code does not enter into that if statement and therefore no changes are done to the not null value of the column. |
| Comments |
| Comment by Lea Haensenberger [ 16/Nov/10 ] |
|
I recreated the bug report in the doctrine 1 project since it rather belongs there. |
[DMIG-12] createIndexSql and dropIndexSql don't use the same logic to get the index name Created: 28/Oct/10 Updated: 16/Nov/10 Resolved: 16/Nov/10 |
|
| Status: | Resolved |
| Project: | Doctrine Migrations |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Lea Haensenberger | Assignee: | Jonathan H. Wage |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Environment: |
Postgres 8.4 |
||
| Description |
|
In the class Doctrine_Export the functions for creating and dropping indexes do not use the same logic to get the name of the index to be created or dropped. When creating an index $this->conn->quoteIdentifier() is called on the index name. We use the migrations with a Postgres 8.4 database. |
| Comments |
| Comment by Lea Haensenberger [ 16/Nov/10 ] |
|
I recreated the bug report in the doctrine 1 project since it rather belongs there. |
[DMIG-10] Syntax error in migration script Created: 27/Oct/10 Updated: 08/Dec/10 Resolved: 08/Dec/10 |
|
| Status: | Resolved |
| Project: | Doctrine Migrations |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Sebastian Hoitz | Assignee: | Jonathan H. Wage |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Description |
|
The migration script created a php line like this: $this->_addSql('ALTER TABLE ... DEFAULT '0''); Which creates a syntax error in the php file. |
| Comments |
| Comment by Jonathan H. Wage [ 08/Dec/10 ] |
|
This should take care of it |
[DMIG-9] table "contact_attribute" already exists - with mappedSuperClass Created: 25/Oct/10 Updated: 26/Nov/10 Resolved: 26/Nov/10 |
|
| Status: | Resolved |
| Project: | Doctrine Migrations |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Sebastian Hoitz | Assignee: | Jonathan H. Wage |
| Resolution: | Cannot Reproduce | Votes: | 0 |
| Labels: | None | ||
| Description |
|
I have a class App_Model_Contact_Attribute: App_Model_Contact_Attribute:
type: mappedSuperclass
inheritanceType: SINGLE_TABLE
table: contact_attribute
discriminatorColumn:
name: type
type: string
length: 20
columnDefinition: "varchar(20) not null"
discriminatorMap:
emailAddress: App_Model_Contact_EmailAddress
twitterAccount: App_Model_Contact_TwitterAccount
id:
id:
type: integer
columnDefinition: "int unsigned not null auto_increment"
generator:
strategy: AUTO
fields:
value:
type: string
notnull: true
columnDefinition: "varchar(45)"
manyToOne:
contact:
joinColumn:
name: contactID
referencedColumnName: id
columnDefinition: "int not null unsigned"
targetEntity: App_Model_Contact
fetch: EAGER
cascade: [persist]
and a class App_Model_Contact_EmailAddress and App_Model_Contact_TwitterAccount. Both yml files look similar to this: App_Model_Contact_TwitterAccount: type: entity Now, when I want to execute migrations:diff it always fails giving me the message: "Table contact_attribute already exists". This probably has to do with the mappedSuperClass declaration in my models. |
| Comments |
| Comment by Sebastian Hoitz [ 26/Nov/10 ] |
|
This bug does not seem to occur anymore. |
[DMIG-23] Doctrine migrations MySQL only? Created: 14/Jul/11 Updated: 17/Nov/11 Resolved: 17/Nov/11 |
|
| Status: | Resolved |
| Project: | Doctrine Migrations |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Yaroslav Zenin | Assignee: | Benjamin Eberlei |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Description |
|
Today I have started with implemention migrations in my project. /**
* Returns the current migrated version from the versions table.
*
* @return bool $currentVersion
*/
public function getCurrentVersion()
{
$this->createMigrationTable();
$result = $this->connection->fetchColumn("SELECT version FROM " . $this->migrationsTableName . " ORDER BY version DESC LIMIT 1");
return $result !== false ? (string) $result : '0';
}
In my project I use MSSQL db. |
| Comments |
| Comment by Kim Hemsø [ 16/Nov/11 ] |
|
Seem this is already been fixed: $sql = "SELECT version FROM " . $this->migrationsTableName . " ORDER BY version DESC"; You can skip my PR-52, if you want since. My plan was to fix it with the query builder |
| Comment by Benjamin Eberlei [ 17/Nov/11 ] |
|
Was already fixed |
[DMIG-22] $table->renameColumn doesn't work Created: 21/Jun/11 Updated: 30/Jun/12 Resolved: 30/Jun/12 |
|
| Status: | Resolved |
| Project: | Doctrine Migrations |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Stefan Klug | Assignee: | Benjamin Eberlei |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Environment: |
php 5.3, current git master |
||
| Description |
|
In my case $table->renameColumn('old', 'new') resulted only in a "drop column 'old'". |
| Comments |
| Comment by Benjamin Eberlei [ 30/Jun/12 ] |
|
We removed the function because of that, see reason here https://github.com/doctrine/dbal/commit/9b0bd8817cb74c4aefba043c7e59f94641cc5b15 |
[DMIG-34] Column names not escaped with backticks Created: 15/Feb/12 Updated: 15/Feb/12 Resolved: 15/Feb/12 |
|
| Status: | Resolved |
| Project: | Doctrine Migrations |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Matthew Baggett | Assignee: | Benjamin Eberlei |
| Resolution: | Invalid | Votes: | 0 |
| Labels: | None | ||
| Environment: |
MySQL & Linux |
||
| Description |
|
Generated from an Entity with a variable named access_key, with a column name of "key". Generated MySQL table constructor fails, name is not escaped with backticks. |
| Comments |
| Comment by Benjamin Eberlei [ 15/Feb/12 ] |
|
This is not a bug, you have to explicitly force escpaing manually by giving @Column(name="``key`") in your mapping (or xml/yml equivalent). Automatic escaping leads to problems, that is why w edont support it. |
[DMIG-20] migrations try to create an index with name "primary" for ManyToMany associations Created: 06/Mar/11 Updated: 26/Jun/11 Resolved: 26/Jun/11 |
|
| Status: | Resolved |
| Project: | Doctrine Migrations |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | arnaud-lb | Assignee: | Jonathan H. Wage |
| Resolution: | Fixed | Votes: | 1 |
| Labels: | None | ||
| Description |
|
For ManyToMany associations, migrations try to create a unique index on (joinColumn, inverseJoinColumn) having name "primary": CREATE UNIQUE INDEX primary ON join_table (joinColumn, inverseJoinColumn); Which results in a syntax error on MySQL (primary is also an invalid key name). |
| Comments |
| Comment by Karsten Dambekalns [ 25/Jun/11 ] |
|
Caused by / related to |
| Comment by arnaud-lb [ 26/Jun/11 ] |
|
Fixed by http://www.doctrine-project.org/jira/browse/DBAL-126 |
[DMIG-7] migrations:diff could not be found Created: 18/Aug/10 Updated: 15/Feb/11 Resolved: 15/Feb/11 |
|
| Status: | Resolved |
| Project: | Doctrine Migrations |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Ting Wang | Assignee: | Jonathan H. Wage |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Environment: |
linux, http://svn.github.com/doctrine/migrations.git, revision 40 |
||
| Attachments: |
|
| Description |
|
./doctrine list migrations didn't list diff although the diff command is added in doctrine.php. This could be the problem of configure() in DiffCommand.php. The parent::configure() is called after the the configuration of diff command. So the name etc of the diff command is overwritten by the father class, namely "generate". |
| Comments |
| Comment by Benjamin Eberlei [ 15/Feb/11 ] |
|
Fixed already |
[DMIG-5] migrations:generate incorrect version Created: 21/Jun/10 Updated: 15/Feb/11 Resolved: 15/Feb/11 |
|
| Status: | Resolved |
| Project: | Doctrine Migrations |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Tom Van Looy | Assignee: | Benjamin Eberlei |
| Resolution: | Invalid | Votes: | 0 |
| Labels: | None | ||
| Environment: |
Linux Ubuntu |
||
| Description |
|
in Doctrine/DBAL/Migrations/Tools/Console/Command/GenerateCommand.php $version = date('YmdHms'); must be $version = date('YmdHis'); |
| Comments |
| Comment by Benjamin Eberlei [ 15/Feb/11 ] |
|
Fixed already. |
[DMIG-4] Case sensitive include Created: 18/Jun/10 Updated: 18/Jun/10 Resolved: 18/Jun/10 |
|
| Status: | Resolved |
| Project: | Doctrine Migrations |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Tom Van Looy | Assignee: | Jonathan H. Wage |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Environment: |
Linux Ubuntu |
||
| Description |
|
use Doctrine\Dbal\Connection, This can't be upper/lowercase. DBAL must be in uppercase every time. |
| Comments |
| Comment by Jonathan H. Wage [ 18/Jun/10 ] |
|
Fixed issue with case in use statement http://github.com/doctrine/migrations/commit/eda8b0b0ee9f9bddb7b73ee956d2106e26b80794 |
[DMIG-3] AbstractCommand depends on ORM Package Created: 16/Jun/10 Updated: 16/Jun/10 Resolved: 16/Jun/10 |
|
| Status: | Resolved |
| Project: | Doctrine Migrations |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major |
| Reporter: | Benjamin Eberlei | Assignee: | Jonathan H. Wage |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Description |
|
The Abstractcommand uses the Entity Manager instead of accessing the DBAL Connection directly through the helperset. This makes it impossible to use migrations without the ORM. The ORM however is only of any interest in the DiffCommand, the other commands don't need access to any EM related functionality. |
[DMIG-2] Creating columns of typ SET fails to set default value Created: 08/Jun/10 Updated: 08/Jun/10 Resolved: 08/Jun/10 |
|
| Status: | Resolved |
| Project: | Doctrine Migrations |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Fredrik | Assignee: | Jonathan H. Wage |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Environment: |
Doctrine 1.2.2 |
||
| Description |
|
When writing a migration class for a table I wanted to add a new column of the SET type. I've set the notnull option and a default value, but Doctrine fails to generate the correct SQL. Migration function: MySQL error (contains the generated SQL): After a bit of debugging I've found the problem, Doctrine_Formatter::quote() doesn't know how to handle set. Simply adding 'set' to the switch right below 'enum' will make it work as it should. — lib/Doctrine/Formatter.php |
| Comments |
| Comment by Fredrik [ 08/Jun/10 ] |
|
I hope I put this into the right project, wasn't sure if this belonged in "Doctrine 1" but this project is called "Doctrine Migrations" so here it went. |
| Comment by Jonathan H. Wage [ 08/Jun/10 ] |
|
This is actually for the Doctrine 2 Migrations project. The Doctrine 1 migrations were a part of the actual Doctrine 1 library. Everything was all coupled together in Doctrine 1. We only split things up for Doctrine 2. |
| Comment by Fredrik [ 08/Jun/10 ] |
|
Oh, I'm sorry. Should I create a new issue under Doctrine 1 to have it fixed there? |
| Comment by Jonathan H. Wage [ 08/Jun/10 ] |
|
No, I already fixed the issue. Just for future reference |
[DMIG-39] Issue when using serjal columns in PostgreSQL with Doctrine ORM Identity fields Created: 24/Apr/13 Updated: 24/Apr/13 Resolved: 24/Apr/13 |
|
| Status: | Resolved |
| Project: | Doctrine Migrations |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | jos de witte | Assignee: | Marco Pivetta |
| Resolution: | Invalid | Votes: | 0 |
| Labels: | postgresql, schematool | ||
| Environment: |
PostgreSQL and migrations |
||
| Description |
|
When using Doctrine ORM mapping fields like this:
/**
* @var integer
*
* @ORM\Column(name="id", type="integer", nullable=false)
* @ORM\Id
* @ORM\GeneratedValue(strategy="IDENTITY")
* @ORM\SequenceGenerator(sequenceName="schemaname.tablename_id_seq", allocationSize=1, initialValue=1)
*/
private $id;
It first creates the migration perfectly as a serial column with the correct schema. However when making a new migration diff it generates DROP statements for every sequence for these id, so we have to remove them manually every time. |
| Comments |
| Comment by Marco Pivetta [ 24/Apr/13 ] |
|
This is a DBAL problem. Please verify this with the DBAL diff tools (latest master) only and eventually report a DBAL issue without involving migrations. |
[DMIG-40] DBAL Enum fields migration issue / PostgreSQL Created: 24/Apr/13 Updated: 24/Apr/13 Resolved: 24/Apr/13 |
|
| Status: | Resolved |
| Project: | Doctrine Migrations |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | jos de witte | Assignee: | Marco Pivetta |
| Resolution: | Invalid | Votes: | 0 |
| Labels: | postgresql, schematool | ||
| Environment: |
PostgreSQL and migrations |
||
| Description |
|
When using Custom Doctrine DBAL Enums the migration created using diff works fine the first time. However the next time it generates a SQL statement trying to change to field type to INT from integer; (Redundant) "ALTER schemaname.fieldname SET" .. And that's it. |
| Comments |
| Comment by Marco Pivetta [ 24/Apr/13 ] |
|
This is a DBAL issue. Please verify the issue using the DBAL schema tools (latest master) only and eventually open a DBAL issue. |
[DMIG-11] Comparer always detects changes when using columnDefinition in mapping definitions Created: 28/Oct/10 Updated: 15/Feb/11 Resolved: 15/Feb/11 |
|
| Status: | Resolved |
| Project: | Doctrine Migrations |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Minor |
| Reporter: | Sebastian Hoitz | Assignee: | Benjamin Eberlei |
| Resolution: | Invalid | Votes: | 0 |
| Labels: | None | ||
| Description |
|
The migration diff command always thinks that my model definitions have changed, when I use the manual columnDefinition on a timestamp column: dateUpdated:
type: datetime
columnDefinition: TIMESTAMP DEFAULT CURRENT_TIMESTAMP NOT NULL
This always results in a migration script like this: <?php
namespace SuplifyApiMigrations;
use Doctrine\DBAL\Migrations\AbstractMigration,
Doctrine\DBAL\Schema\Schema;
class Version20101028121948 extends AbstractMigration
{
public function up(Schema $schema)
{
$this->_addSql('ALTER TABLE ticket CHANGE dateUpdated dateUpdated TIMESTAMP DEFAULT CURRENT_TIMESTAMP NOT NULL');
}
public function down(Schema $schema)
{
$this->_addSql('ALTER TABLE ticket CHANGE dateUpdated dateUpdated DATETIME DEFAULT CURRENT_TIMESTAMP NOT NULL');
}
}
As you can see, the columns look exactly the same. Doctrine just does not seem to parse the manual columnDefinition and compare its result. |
| Comments |
| Comment by Benjamin Eberlei [ 15/Feb/11 ] |
|
Its not possible to fix this issue, its actually a drawback of using "columnDefinition", i started documenting this in the ORM docs. |
[DMIG-16] incorrect class name Created: 15/Jan/11 Updated: 15/Feb/11 Resolved: 15/Feb/11 |
|
| Status: | Resolved |
| Project: | Doctrine Migrations |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Documentation | Priority: | Minor |
| Reporter: | Stepan Tanasiychuk | Assignee: | Benjamin Eberlei |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Description |
|
http://www.doctrine-project.org/projects/migrations/2.0/docs/reference/introduction/en#introduction
bug in "\Symfony\Component_s_\Console\Helper\DialogHelper" => "\Symfony\Component\Console\Helper\DialogHelper()" |
| Comments |
| Comment by Benjamin Eberlei [ 15/Feb/11 ] |
|
Fixed. |