[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-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-37] PostgreSQL generated SQL statements in migrations that use doublequotes create syntax errors in PHP Created: 28/Mar/13 Updated: 28/Mar/13 |
|
| Status: | Open |
| Project: | Doctrine Migrations |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | jos de witte | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | PostgreSQL, schematool | ||
| Environment: |
PostgreSQL backend, using migration versions with field or schemanames that use reserved names. |
||
| Description |
|
When using some reserved field names in PostgreSQL DBAL, the generated SQL statements will quote those field names. (Make a table with fieldname "left" for example) When the migrationversion is generated, the doublequote is not escaped: addSQL("ALTER table x add column "left" integer"); This does not compile of course, should be addSQL("ALTER table x add column \"left\" integer"); Regards! |
[DDC-2489] Missing semicolon in schema update tool, using dump-sql argument Created: 05/Jun/13 Updated: 12/Jun/13 Resolved: 12/Jun/13 |
|
| Status: | Closed |
| Project: | Doctrine 2 - ORM |
| Component/s: | ORM, Tools |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Minor |
| Reporter: | Robert-Jan | Assignee: | Guilherme Blanco |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | Cli, schematool | ||
| Description |
|
When executing the schema-tool update script, using the --dump-sql argument (e.g. "app/console doctrine:schema:update --dump-sql" in a symfony2 project), the semicolon behind the last query is missing. |
| Comments |
| Comment by Guilherme Blanco [ 12/Jun/13 ] |
|
Fixed in https://github.com/doctrine/doctrine2/commit/0d834d0bd4015de2c103a03592c1543399f1b363 |
[DDC-2469] SQLite handling for ENUM-Fields Created: 24/May/13 Updated: 24/May/13 Resolved: 24/May/13 |
|
| Status: | Resolved |
| Project: | Doctrine 2 - ORM |
| Component/s: | Mapping Drivers |
| Affects Version/s: | Git Master |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Bug | Priority: | Major |
| Reporter: | Andy Rosslau | Assignee: | Marco Pivetta |
| Resolution: | Invalid | Votes: | 0 |
| Labels: | query, schematool, sqlite | ||
| Description |
|
SQLite doesn't support ENUMS! But when I try create the schema of the following Entity Doctrine generates this "CREATE TABLE" - Statement:
CREATE TABLE Entity ([...] NOT NULL, taxation ENUM('incl', 'excl'), maxNumbe[...]
class Entity {
...
/**
* @var string
*
* @ORM\Column(type="string", columnDefinition="ENUM('incl', 'excl')")
*/
private $taxation = self::TAXATION_INCL;
...
}
Produces this error: SQLSTATE[HY000]: General error: 1 near "'incl'": syntax error' |
| Comments |
| Comment by Marco Pivetta [ 24/May/13 ] |
|
Usage of columnDefinition in annotations or generally metadata mappings is all about vendor specific syntax. `columnDefinition` is designed to allow overriding the default ORM column generated DDL to build vendor specific syntax/types, therefore the issue is invalid |
[DDC-2464] useless index for the middle table of many-to-many relationship Created: 21/May/13 Updated: 21/May/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | Tools |
| Affects Version/s: | Git Master |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Improvement | Priority: | Minor |
| Reporter: | scourgen | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | ddl, schematool | ||
| Description |
|
I have entity A and B, the relationship between A and B is many-to-many. which means Doctrine2 will generate a middle table called AB for me. entity A:
class Station {
/**
* @ORM\ManyToMany(targetEntity="Fun", mappedBy="stations")
*/
protected $funs;
}
entity B:
class Fun {
/**
* @ORM\ManyToMany(targetEntity="Station", inversedBy="funs")
* @ORM\JoinTable(name="stations_have_funs")
*/
protected $stations;
}
the schema of middle table stations_have_funs: CREATE TABLE `stations_have_funs` ( `fun_id` int(11) NOT NULL, `station_id` int(11) NOT NULL, PRIMARY KEY (`fun_id`,`station_id`), KEY `IDX_45C921911CA4BE49` (`fun_id`), KEY `IDX_45C9219121BDB235` (`station_id`), CONSTRAINT `FK_45C921911CA4BE49` FOREIGN KEY (`fun_id`) REFERENCES `funs` (`id`) ON DELETE CASCADE, CONSTRAINT `FK_45C9219121BDB235` FOREIGN KEY (`station_id`) REFERENCES `stations` (`id`) ON DELETE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci; I noticed that there are 2 useless index(fun_id and station_id). Since fun_id and station_id are the primary key of this table. Do we really need 2 extra/duplicated index ? |
[DDC-2425] Parent entity sometimes fails to load when validating/updating schema. Created: 03/May/13 Updated: 03/May/13 Resolved: 03/May/13 |
|
| Status: | Resolved |
| Project: | Doctrine 2 - ORM |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Bug | Priority: | Trivial |
| Reporter: | Scott Gibson | Assignee: | Benjamin Eberlei |
| Resolution: | Invalid | Votes: | 0 |
| Labels: | Cli, orm, schematool | ||
| Environment: |
Debian 6.0.6 x64 |
||
| Description |
|
Should not have reported, was a stupid mistake on my part. |
[DDC-2421] Many-To-Many relation creation failed when using non PK entity field Created: 29/Apr/13 Updated: 01/May/13 Resolved: 01/May/13 |
|
| Status: | Resolved |
| Project: | Doctrine 2 - ORM |
| Component/s: | Mapping Drivers, Tools |
| Affects Version/s: | Git Master, 2.3.3 |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Bug | Priority: | Major |
| Reporter: | Bruno CHALOPIN | Assignee: | Benjamin Eberlei |
| Resolution: | Invalid | Votes: | 0 |
| Labels: | schematool | ||
| Environment: |
Ubuntu linux 12.04, php 5.4.9 |
||
| Description |
|
Given these entities : /** * Class Domain * * @ORM\Entity * @ORM\Table(name="profils_domains") */ class Domain { /** * @var string * * @ORM\Id * @ORM\Column(type="string", length=22, nullable=false) */ protected $name = ''; } /** * Class Web * * @ORM\Entity * @ORM\Table(name="profils_webs", * uniqueConstraints={@ORM\UniqueConstraint(name="web_unique",columns={"name", "domain"})} * ) */ class Web { /** * @var integer * * @ORM\Id * @ORM\GeneratedValue * @ORM\Column(type="integer", nullable=false) */ protected $id; /** * @var string * * @ORM\Column(type="string", length=22, nullable=false) */ protected $name = ''; /** * @var Domain * * @ORM\ManyToOne(targetEntity="Domain", fetch="LAZY") * @ORM\JoinColumn(name="domain", referencedColumnName="name", nullable=false, onDelete="CASCADE") */ protected $domain; } /** * Class WebsGroup * * @ORM\Entity * @ORM\Table(name="profils_websgroups", * uniqueConstraints={@ORM\UniqueConstraint(name="websgroup_unique",columns={"name", "domain"})} * ) */ class WebsGroup { /** * @var integer * * @ORM\Id * @ORM\GeneratedValue * @ORM\Column(type="integer", nullable=false) */ protected $id; /** * @var string * * @ORM\Column(type="string", length=22, nullable=false) */ protected $name = ''; /** * @var Domain * * @ORM\ManyToOne(targetEntity="Domain", fetch="LAZY") * @ORM\JoinColumn(name="domain", referencedColumnName="name", nullable=false, onDelete="CASCADE") */ protected $domain; /** * @var ArrayCollection * * @ORM\ManyToMany(targetEntity="Web", indexBy="id", fetch="EXTRA_LAZY") * @ORM\JoinTable(name="profils_websgroups_webs", * joinColumns={ * @ORM\JoinColumn(name="websgroup_id", referencedColumnName="id", onDelete="CASCADE"), * @ORM\JoinColumn(name="domain", referencedColumnName="domain", onDelete="CASCADE") * }, * inverseJoinColumns={ * @ORM\JoinColumn(name="web_id", referencedColumnName="id", onDelete="CASCADE"), * @ORM\JoinColumn(name="domain", referencedColumnName="domain", onDelete="CASCADE") * } * ) */ protected $webs; } I've got a domain, some web sites per domain and websgroups which group web sites. I want to be sure in my database that a web group from a domain D can contain only web sites from the very same domain but when calling the console tool for creating my schema it raise :
[Doctrine\ORM\ORMException]
Column name `domain` referenced for relation from Entity\WebsGroup towards Entity\Web does not exist.
It's because domain is already an association to an entity which and is not part of the primary key. I've quick fixed getDefiningClass from Doctrine\ORM\Tools\SchemaTool to make it work but i really don't know if it's the proper way :
private function getDefiningClass($class, $referencedColumnName)
{
$referencedFieldName = $class->getFieldName($referencedColumnName);
if ($class->hasField($referencedFieldName)) {
return array($class, $referencedFieldName);
} else if (in_array($referencedColumnName, $class->getIdentifierColumnNames())) {
// it seems to be an entity as foreign key
foreach ($class->getIdentifierFieldNames() as $fieldName) {
if ($class->hasAssociation($fieldName) && $class->getSingleAssociationJoinColumnName($fieldName) == $referencedColumnName) {
return $this->getDefiningClass(
$this->em->getClassMetadata($class->associationMappings[$fieldName]['targetEntity']),
$class->getSingleAssociationReferencedJoinColumnName($fieldName)
);
}
}
} else if (in_array($referencedColumnName, $class->getAssociationNames())) {
return $this->getDefiningClass(
$this->em->getClassMetadata($class->associationMappings[$referencedColumnName]['targetEntity']),
$class->getSingleAssociationReferencedJoinColumnName($referencedColumnName)
);
}
return null;
}
|
| Comments |
| Comment by Fabio B. Silva [ 29/Apr/13 ] |
|
Bruno CHALOPIN Except for some CS this fix seems good. If you have time you can send as pull request |
| Comment by Bruno CHALOPIN [ 30/Apr/13 ] |
|
I've start making a PR and a test case but it is linked to http://www.doctrine-project.org/jira/browse/DDC-2413 |
| Comment by Benjamin Eberlei [ 01/May/13 ] |
|
You cannot use a reference column that is not a primary key. Doctrine does not support this. |
[DDC-2288] Schema Tool doesn't update collation on table level Created: 08/Feb/13 Updated: 08/Feb/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | Mapping Drivers, Tools |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Minor |
| Reporter: | Rickard Andersson | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | collation, schematool | ||
| Description |
|
In Symfony2, when updating the collation option of a table, the schema tool doesn't recognize the change: Changing from: * @ORM\Table() To:
* @ORM\Table(options={"collate"="utf8_swedish_ci"})
Results in: $ php app/console doctrine:schema:update --dump-sql Nothing to update - your database is already in sync with the current entity metadata. |
[DDC-2238] doctrine:schema:update partially broken Created: 11/Jan/13 Updated: 01/May/13 Resolved: 01/May/13 |
|
| Status: | Resolved |
| Project: | Doctrine 2 - ORM |
| Component/s: | Tools |
| Affects Version/s: | 2.3 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Tom Vogt | Assignee: | Benjamin Eberlei |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | postgresql, schematool | ||
| Environment: |
OS X 10.7.5 also confirmed on: |
||
| Attachments: |
|
||||||||
| Issue Links: |
|
||||||||
| Description |
|
the app/console doctrine:schema:update command generates a seemingly random number of statements like these: ALTER TABLE geodata ALTER humidity SET ; which are obvious invalid SQL commands. The mappings are fine, validate and the application works just fine. Here's an example from the mapping files including two of the above statements: <field name="coast" type="boolean"/> I am using doctrine2-spatial as an extension for GIS information. This problem shows up both in entities using spatial data and entities not using spatial data. I'll gladly help debug this, as right now I can't update my dev database with --force, I need to use --dump-sql and filter out the invalid lines. |
| Comments |
| Comment by Benjamin Eberlei [ 12/Jan/13 ] |
|
Can you dump the SchemaDiff/ColumnDiff instances that are returned from lib/Doctrine/DBAL/Schema/Comparator.php? |
| Comment by Tom Vogt [ 12/Jan/13 ] |
|
requested dump of SchemaDiff |
| Comment by Tom Vogt [ 12/Jan/13 ] |
|
added in the file schemadiff.txt - I added this in Schematool.php - getUpdateSchemaSql(): $comparator = new Comparator(); if you need other output, just tell me what entity to dump and where. I'll be happy to help. The file also contains the buggy update statements it creates towards the end. There's a few non-crucial bugs included, where it alters the geospatial columns to themselves (i.e. river.course already is a geometry/linestring). I don't worry about those because they don't break anything. |
| Comment by Tom Vogt [ 15/Apr/13 ] |
|
Is there any update on this? I'm still having this issue, with many different entities, always the same problem, for example: ALTER TABLE event ALTER priority SET ; Which is an integer field on an entity that doesn't have any GIS elements, so I'm not even sure if it's caused by that anymore. |
| Comment by Benjamin Eberlei [ 01/May/13 ] |
|
Tom Vogt I added a fix for PostgreSQL today, can you verify again if this works? Its included in the 2.3 branch. |
| Comment by Benjamin Eberlei [ 01/May/13 ] |
|
Duplicate of http://www.doctrine-project.org/jira/browse/DBAL-504 |
[DDC-2135] Setting column defaults using options in the annotations causes redundant alter statements Created: 09/Nov/12 Updated: 01/May/13 Resolved: 01/May/13 |
|
| Status: | Resolved |
| Project: | Doctrine 2 - ORM |
| Component/s: | ORM |
| Affects Version/s: | 2.2.2 |
| Fix Version/s: | 2.3.4 |
| Security Level: | All |
| Type: | Bug | Priority: | Major |
| Reporter: | Cory Comer | Assignee: | Benjamin Eberlei |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | Cli, schematool | ||
| Description |
|
When using the Column annotation on an entity and passing the options parameter to set a default value for a column, the doctrine cli will generate the alter statement every time the schema-tool is run. This doesn't break the functionality of updating the schema using the cli but when you have multiple entities using default values in this manner it becomes cumbersome to investigate issues during updates that fail and you need to dump the generated sql to examine. Use case: We have a number of entities that include 'boolean' flags. The data for these entities is inserted into the database through an integration process handled by another application. For all of the flags we want to set a default value of 0 to avoid having to modify the integration scripts when a new flag is added to an entity and the data is not available yet. Example entity: /** * @ORM\Entity * @ORM\Table(name="example") */ class Example { /** * @ORM\Id * @ORM\Column(type="integer") */ protected $id; /** @ORM\Column(type="integer", options={"default" = 0}) */ protected $disabled; } $ php bin/doctrine orm:schema-tool:update --dump-sql ALTER TABLE example CHANGE disabled disabled TINYINT(1) DEFAULT '0' NOT NULL; This alter statement is generated on every run of the schema-tool even though the schema has already been altered. |
| Comments |
| Comment by Benjamin Eberlei [ 01/May/13 ] |
|
This is fixed for 2.3.4 |
[DDC-2119] Problem with inheritance type: INHERITANCE_TYPE_NONE and INHERITANCE_TYPE_TABLE_PER_CLASS Created: 03/Nov/12 Updated: 08/Apr/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | DQL, Tools |
| Affects Version/s: | 2.1 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | SergSW | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | dql, schematool | ||
| Attachments: |
|
| Description |
|
I tried to create inheritance entities with save policy table per class. I had found a solution. In Doctrine\ORM\Tools\SchemaTool private function _gatherRelationsSql($class, $table, $schema) { foreach ($class->associationMappings as $fieldName => $mapping) { // if (isset($mapping['inherited'])) { // - old version /** * SSW * It's the solution */ if (isset($mapping['inherited']) && !$class->isInheritanceTypeNone() && !$class->isInheritanceTypeTablePerClass() ) { continue; } $foreignClass = $this->_em->getClassMetadata($mapping['targetEntity']); ... But it was enough. In DQL query a simple query was made wrong. I had found a solution again. public function walkSelectExpression($selectExpression) ... // original => if (isset($mapping['inherited'])){ // It's the solution if (isset($mapping['inherited']) && !$class->isInheritanceTypeNone() && !$class->isInheritanceTypeTablePerClass()) { $tableName = $this->_em->getClassMetadata($mapping['inherited'])->table['name']; } else { $tableName = $class->table['name']; } ... This problems are topical for inheritance type: INHERITANCE_TYPE_NONE and INHERITANCE_TYPE_TABLE_PER_CLASS. I don't know, may be my solutions are wrong. But some programmers want to correctly work with INHERITANCE_TYPE_TABLE_PER_CLASS. Sorry for my english. |
| Comments |
| Comment by Fabio B. Silva [ 05/Nov/12 ] |
|
Hi SergSW Could you try to write a failing test case ? Thanks |
| Comment by SergSW [ 06/Nov/12 ] |
|
SSW/TestBundle with the problem |
| Comment by SergSW [ 07/Nov/12 ] |
|
I install the Symfony v2.0.18. and made small TestBundle. |
| Comment by SergSW [ 07/Nov/12 ] |
|
MySQL dump |
| Comment by Benjamin Eberlei [ 12/Nov/12 ] |
|
Adjusted example formatting, don't apologize for your English, thanks for the report! |
| Comment by Benjamin Eberlei [ 24/Dec/12 ] |
|
What version of 2.1 are you using? We don't actually support 2.1 anymore. Inheritance has always worked as used in hundrets of unit-tests, this changes look quite major a bug to have been missed before. I can't really explain whats happening here. |
| Comment by Marco Pivetta [ 23/Jan/13 ] |
|
SergSW news? |
[DDC-2011] Schema tool fail to handle ManyToMany relation with an existing joinTable Created: 04/Sep/12 Updated: 09/Feb/13 Resolved: 09/Feb/13 |
|
| Status: | Resolved |
| Project: | Doctrine 2 - ORM |
| Component/s: | Tools |
| Affects Version/s: | Git Master |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Bug | Priority: | Minor |
| Reporter: | Erwan Richard | Assignee: | Benjamin Eberlei |
| Resolution: | Won't Fix | Votes: | 2 |
| Labels: | schematool | ||
| Description |
|
The schemaTool fail with a Doctrine\DBAL\Schema\SchemaException when trying to handle ManyToMany relation with an existing joinTable. My use case : I'm using the Tree DoctrineExtension with the Closure strategy. It create a mapping between my Category entity and a CategoryClosure entity. For conveniency, I've setup a ManyToMany relation between Category and Category with the CategoryClosure table as joinTable. Doctrine ORM handle perfectly this case but the schema tool is failing with : |
| Comments |
| Comment by Alexander [ 09/Feb/13 ] |
|
You can't expect the schematool to play nice if you use the table of an entity as m2m table. |
[DBAL-483] default values make orm:validate-schema fail Created: 04/Apr/13 Updated: 01/May/13 Resolved: 01/May/13 |
|
| Status: | Resolved |
| Project: | Doctrine DBAL |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 2.3.4 |
| Security Level: | All |
| Type: | Bug | Priority: | Major |
| Reporter: | Till | Assignee: | Benjamin Eberlei |
| Resolution: | Fixed | Votes: | 1 |
| Labels: | schematool | ||
| Environment: |
MySQL, PHP 5.3, Doctrine 2.3 |
||
| Description |
% ./bin/doctrine.php --env=development orm:schema-tool:update --dump-sql ALTER TABLE groups CHANGE active active TINYINT(1) DEFAULT '1' NOT NULL; ALTER TABLE module ADD root_order INT DEFAULT 0 NOT NULL % ./bin/doctrine.php --env=development orm:schema-tool:update --force Updating database schema... Database schema updated successfully! "2" queries were executed % ./bin/doctrine.php --env=development orm:schema-tool:update --dump-sql ALTER TABLE groups CHANGE active active TINYINT(1) DEFAULT '1' NOT NULL; ALTER TABLE module CHANGE root_order root_order INT DEFAULT 0 NOT NULL My entities define these columns like this: Group
/**
* @ORM\Column(name="active", type="boolean", options={"default":true})
*/
private $active = true;
Module
/**
* @ORM\Column(name="root_order", type="integer", options={"default":0})
*/
private $rootOrder = 0;
|
| Comments |
| Comment by Felix Kaser [ 30/Apr/13 ] |
|
We are having the same issue. Is there any workaround for this? |
| Comment by Felix Kaser [ 30/Apr/13 ] |
|
I've investigated a bit and noticed several things:
So based on this I would say:
Please correct me if I'm wrong |
[DBAL-482] SQL Server Schema Manager returns incorrect value for autoincrement on IDENTITY columns Created: 03/Apr/13 Updated: 01/May/13 Resolved: 01/May/13 |
|
| Status: | Resolved |
| Project: | Doctrine DBAL |
| Component/s: | Schema Managers |
| Affects Version/s: | 2.2, 2.3, 2.3.3 |
| Fix Version/s: | 2.3.4 |
| Security Level: | All |
| Type: | Bug | Priority: | Minor |
| Reporter: | William Schaller | Assignee: | Benjamin Eberlei |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | schematool, sqlserver, sqlsrv | ||
| Environment: |
SQL Server |
||
| Description |
|
When calculating table diffs, SQLServerSchemaManager returns column definitions for identity columns with _autoincrement set to FALSE. This causes the schema update SQL generation to pump out a The culprit is in DBAL\Schema\SQLServerSchemaManager, starting at line 43: $dbType = strtolower($tableColumn['TYPE_NAME']);
$dbType = strtok($dbType, '(), ');
$autoincrement = false;
if (stripos($dbType, 'identity')) {
$dbType = trim(str_ireplace('identity', '', $dbType));
$autoincrement = true;
}
When the column in question is an identity int column, the TYPE_NAME is "int identity". The second line of the snippet drops the "identity" signifier, causing the following lines that determine autoincrement to do nothing. I simply moved the second line to below the autoincrement block ie: $dbType = strtolower($tableColumn['TYPE_NAME']);
$autoincrement = false;
if (stripos($dbType, 'identity')) {
$dbType = trim(str_ireplace('identity', '', $dbType));
$autoincrement = true;
}
$dbType = strtok($dbType, '(), ');
This change solves this issue for me, and as far as I can tell, has no other consequences. |
| Comments |
| Comment by Benjamin Eberlei [ 01/May/13 ] |
|
Fixed for 2.3.4 and was fixed for 2.4 in a different way already. |
[DBAL-474] SchemaManager / Connection on PostgreSQL platform does not respect filterExpression for sequences Created: 27/Mar/13 Updated: 24/Apr/13 |
|
| Status: | Awaiting Feedback |
| Project: | Doctrine DBAL |
| Component/s: | Schema Managers |
| Affects Version/s: | 2.2.2 |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Bug | Priority: | Major |
| Reporter: | jos de witte | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | postgresql, schematool | ||
| Environment: |
Windows & Linux |
||
| Description |
|
Dear Symfony team, the filterExpression on AbstractSchemaManager seems not to work for sequences. This only happens under postgres. It seems the way the sequences are handled are the culprit: It tries to get min_value etc of sequences without matching sequence names to the filter expression in advance. If for example access to the sequences is denied, (Different schema without permissions for the current entity manager), any higher-level ORM operations like generating migration versions fail. --------------------- UPDATE the context is when using migrations. Positive regexp expressions do not limit the migration to a single schema. eg ^schemaname.$ |
| Comments |
| Comment by Benjamin Eberlei [ 14/Apr/13 ] |
|
Can you paste an exception trace? I see that filtering is applied to sequences, but your description seems to indicate this happens due to an SQL query much earlier? |
| Comment by jos de witte [ 24/Apr/13 ] |
|
Dear Benjamin, the context is when using migrations. Positive regexp expressions do not limit the migration to a single schema. eg ^schemaname.$ |
[DBAL-420] Schema Drop SQL incorrect on PostgreSQL with entities with GeneratedValue(strategy="IDENTITY") Created: 23/Jan/13 Updated: 14/Apr/13 Resolved: 14/Apr/13 |
|
| Status: | Resolved |
| Project: | Doctrine DBAL |
| Component/s: | Schema Managers |
| Affects Version/s: | 2.3.2 |
| Fix Version/s: | 2.3.4 |
| Security Level: | All |
| Type: | Bug | Priority: | Major |
| Reporter: | Adam Ashley | Assignee: | Benjamin Eberlei |
| Resolution: | Fixed | Votes: | 1 |
| Labels: | postgresql, schematool | ||
| Environment: |
Symfony 2.1, PHP5.4, PostgreSQL 9.1 on Ubuntu 12.04 |
||
| Description |
|
This problem is probably related to # When schema drop is run the following error occurs: SQLSTATE[2BP01]: Dependent objects still exist: 7 ERROR: cannot drop sequence radacct_radacctid_seq because other objects depend on it The source of this problem is the difference between strategy="IDENTITY" and strategy="SEQUENCE" With SEQUENCE doctrine creates the table schema with field type BIGINT and no specified. It then creates a seperate sequence and as far as I can tell takes care of getting and inserting the next id number itself. With IDENTITY doctrine creates the table schema with field type BIGSERIAL and no specified default. Now postgres automatically creates a sequence and creates the column with type BIGINT and sets the DEFAULT to the pgpsql statement required to get the nextval from the sequence. At this point the two differently configured tables will work successfully and identically, except SEQUENCE tables will only get a correct new ID when run through the doctrine code while IDENTITY tables will get the correct new ID whenever an insert is done to the table. Because in the case of an IDENTITY field postgresql creates the field with a default value refering to the sequence the sequence can not be deleted before the table reference is removed. For my case I need the IDENTITY fields to work as we have a RADIUS server that needs to insert into one table which is managed and mapped to an entity in Doctrine. Swapping the order of DROP TABLE and DROP SEQUENCE commands in Doctrine/DBAL/Schema/Visitor/DropSchemaSqlCollector.php in getQueries() line 159. Does not work as a quick fix. The following error occurs as the sequence is quite correctly be dropped along with the table. Doctrine\DBAL\DBALException: An exception occurred while executing 'DROP SEQUENCE radacct_radacctid_seq': SQLSTATE[42P01]: Undefined table: 7 ERROR: sequence "radacct_radacctid_seq" does not exist |
| Comments |
| Comment by Adam Ashley [ 24/Jan/13 ] |
|
This issue also appears to affect Doctrine_Migrations. Generated migrations try to drop and recreate automatically generated sequences associated with SERIAL fields making a mess of the database. |
| Comment by Benjamin Eberlei [ 22/Mar/13 ] |
|
A related Github Pull-Request [GH-289] was opened |
| Comment by Adrien Crivelli [ 12/Apr/13 ] |
|
@Adam Ashley, could you test whether https://github.com/doctrine/dbal/pull/289 solve your issue ? |
| Comment by Doctrine Bot [ 14/Apr/13 ] |
|
A related Github Pull-Request [GH-289] was closed: |
[DBAL-411] Schema updater breaks when using backticks in tablenames. Created: 08/Jan/13 Updated: 08/Jan/13 |
|
| Status: | Open |
| Project: | Doctrine DBAL |
| Component/s: | Schema Managers |
| Affects Version/s: | 2.3.2 |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Bug | Priority: | Minor |
| Reporter: | Endaco | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | schematool | ||
| Environment: |
Debian Linux 6.0, PHP 5.3.3, MySQL 5.1.63 |
||
| Description |
|
When using backticks around table-names (for example "`Order`"), the Doctrine schema update tool wants to recreate all foreign keys on every run. This error was introduced in commit cb3ec49cb4401bd1c8be6ba9671f651802586eaf |
[DBAL-367] Reverse engnering do not work with Oracle DB Created: 18/Oct/12 Updated: 23/Jan/13 |
|
| Status: | Open |
| Project: | Doctrine DBAL |
| Component/s: | Drivers, Schema Managers |
| Affects Version/s: | 2.3 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Zelenin Alexandr | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | Cli, oracle, schematool | ||
| Environment: |
PHP 5.3.3-1ubuntu9.10 with Suhosin-Patch (cli) (built: Feb 11 2012 06:21:15) |
||
| Description |
$ doctrine orm:convert-mapping --filter="ms$ions" xml .
[Doctrine\DBAL\DBALException]
Unknown database type binary_float requested, Doctrine\DBAL\Platforms\OraclePlatform may not support it.
cli-config.php: use Doctrine\Common\Annotations\AnnotationReader; use Doctrine\Common\Annotations\AnnotationRegistry; require_once 'Doctrine/Common/ClassLoader.php'; define('APPLICATION_ENV', "development"); error_reporting(E_ALL); $classLoader = new \Doctrine\Common\ClassLoader('Doctrine'); $classLoader->register(); $config = new \Doctrine\ORM\Configuration(); $config->setProxyDir(__DIR__); $config->setProxyNamespace('Proxies'); $config->setAutoGenerateProxyClasses((APPLICATION_ENV == "development")); AnnotationRegistry::registerFile("Doctrine/ORM/Mapping/Driver/DoctrineAnnotations.php"); $reader = new AnnotationReader(); $driverImpl = new \Doctrine\ORM\Mapping\Driver\AnnotationDriver($reader, array(__DIR__ . "/../php/ru/niifhm/bioinformatics/biodb/model")); $config->setMetadataDriverImpl($driverImpl); if (APPLICATION_ENV == "development") { $cache = new \Doctrine\Common\Cache\ArrayCache(); } else { $cache = new \Doctrine\Common\Cache\ApcCache(); } $config->setMetadataCacheImpl($cache); $config->setQueryCacheImpl($cache); $connectionOptions = array( 'driver' => 'oci8', 'host' => 'host.name', 'dbname' => 'db.name', 'user' => 'user.name', 'password' => 'user.password' ); $em = \Doctrine\ORM\EntityManager::create($connectionOptions, $config); $platform = $em->getConnection()->getDatabasePlatform(); $platform->registerDoctrineTypeMapping('enum', 'string'); $em->getConfiguration()->setMetadataDriverImpl( new \Doctrine\ORM\Mapping\Driver\DatabaseDriver( $em->getConnection()->getSchemaManager() ) ); $helperSet = new \Symfony\Component\Console\Helper\HelperSet(array( 'db' => new \Doctrine\DBAL\Tools\Console\Helper\ConnectionHelper($em->getConnection()), 'em' => new \Doctrine\ORM\Tools\Console\Helper\EntityManagerHelper($em) )); |
| Comments |
| Comment by Marco Pivetta [ 23/Jan/13 ] |
|
Formatting |
[DBAL-346] Generated schema fails on MySQL (BLOB/TEXT cant have DEFAULT value) Created: 19/Sep/12 Updated: 20/Sep/12 Resolved: 20/Sep/12 |
|
| Status: | Resolved |
| Project: | Doctrine DBAL |
| Component/s: | Schema Managers |
| Affects Version/s: | 2.2.2 |
| Fix Version/s: | 2.3 |
| Security Level: | All |
| Type: | Bug | Priority: | Major |
| Reporter: | Sascha Ahmann | Assignee: | Benjamin Eberlei |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | Cli, schematool | ||
| Environment: |
Symfony 2.1.x (dev/master), Doctrine 2.2.3, MySQL 5.5.x |
||
| Description |
|
In my symfony 2.1 project i was including JMSPaymentCoreBundle and did the vanilla installation. After that i ran php app/console doctrine:schema:update --dump-sql php app/console doctrine:schema:update --force A lot of schema updates were done. I ran it again, and two schema updates were still showing up. I then tried to run the two schema updates against my database and MySQL complains with the following error:
Error: 1101 - BLOB/TEXT column 'extended_data' can't have a default value
According to the Documentation BLOB/TEXT indeed cannot have default values. I am not sure why Doctrine thinks it has to set this default value. The statements look like this:
sascha@debian:/var/www/myproject/Symfony$ php app/console doctrine:schema:update --dump-sql
ALTER TABLE payment_instructions CHANGE extended_data extended_data LONGTEXT NOT NULL COMMENT '(DC2Type:extended_payment_data)';
ALTER TABLE financial_transactions CHANGE extended_data extended_data LONGTEXT DEFAULT NULL COMMENT '(DC2Type:extended_payment_data)'
I already reported this problem in the JMSPaymentCoreBundle Issue Queue where i then was referred to over here. Also, i am not sure if Doctrine DBAL is the best match for this issue, so if it is wrong please move it to the right project issue queue. Thank you very much and best of Regards! |