[DBAL-373] Indexes and uniqueConstraints has been ignored Created: 26/Oct/12  Updated: 20/Apr/13

Status: Awaiting Feedback
Project: Doctrine DBAL
Component/s: Schema Managers
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Minor
Reporter: Diego Oliveira Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Ubuntu 12.04 with MySQL 5.5 and PHP 5.4


Attachments: Text File dbal-fixing-373.patch     Text File orm-fixing-373.patch    

 Description   

I using the Doctrine Migrations and when I declared my entity with the indexes section, the index name has been ignored. It's like this:

indexes:
IDX_ADDRESS_CITY:
columns: city_id

but, the diff tools ignore it and give me this code:
$this->addSql("CREATE INDEX IDX_7299B5238BAC62AF ON tb_address (city_id)");

and it should be:
$this->addSql("CREATE INDEX IDX_ADDRESS_CITY ON tb_address (city_id)");

Notice: I open the same bug on the migrations repository in github and @kimhemsoe told me to open here, since this is generated by DBAL component.



 Comments   
Comment by Padraig O'Sullivan [ 11/Dec/12 ]

Did you specify an index name in the indexes property for your entity in your PHP file? In this case, you should have something like:

indexes={@Index(name="IDX_ADDRESS_CITY", columns={"city_id"})}

That should result in the correct SQL being generated. If I modify the above to:

indexes={@Index(columns={"city_id"})}

I also get a migration that has SQL with an auto-generated index name.

Comment by Diego Oliveira [ 02/Feb/13 ]

Yes I did specify a name, as you can see:

uniqueConstraints:
    UNIQUE_STATE_SLUG:
        columns: slug
indexes:
    IDX_USER_ADDRESS:
        columns: address_id

I don't try do to it using annotations because I choose do use yaml to describe my entities. I will take a look on the source code to see if I can fix it and send a PR.

Comment by Diego Oliveira [ 02/Apr/13 ]

I already sent this patch to Guilherme Blanco, but I guess he doesn't have time to take a look on it.

I guess my solution it's not ideal, but it solve the problem and can be a base to make a better solution.

Comment by Benjamin Eberlei [ 20/Apr/13 ]

Diego Oliveira the fix doesn't seem too nice with the additional boolean flag.

I would rather like to fix the root cause instead of adding this solution.

Comment by Benjamin Eberlei [ 20/Apr/13 ]

The issue is tricky, because we cannot just move the index definitions above, they will need the columns, however that directly generates the index in the schema tool. Maybe if the gather join column methods would check if they can add an index already it would work.





[DBAL-292] Multiple use of named parameter doesn't work Created: 12/Jun/12  Updated: 28/Dec/13

Status: Awaiting Feedback
Project: Doctrine DBAL
Component/s: None
Affects Version/s: 2.2.2
Fix Version/s: None
Security Level: All

Type: Bug Priority: Minor
Reporter: Jürgen Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

IIS 7.5, MS-SQL-Server 2005, PHP 5.4.0



 Description   

In the example in the documentation http://doctrine-dbal.readthedocs.org/en/2.0.x/reference/data-retrieval-and-manipulation.html#dynamic-parameters-and-prepared-statements there is the following example:

$sql = "SELECT * FROM users WHERE name = :name OR username = :name";
$stmt = $conn->prepare($sql);
$stmt->bindValue("name", $name);
$stmt->execute();

When I try this example using pdo_sqlsrv I get the following error:
PDOException: SQLSTATE[07002]: [Microsoft][SQL Server Native Client 11.0]COUNT field incorrect or syntax error

When I use instead the parameters name1 and name2 the query works as expected.



 Comments   
Comment by Alexander [ 07/Jul/12 ]

Are you sure you were using the 2.2.2 version of the ORM? Can you try to reproduce this with the latest master?

Comment by Steve Müller [ 28/Dec/13 ]

Jürgen ping. I cannot reproduce this error, either. Can you please try to reproduce this with the latest master branch? Otherwise I will close this ticket.





Generated at Tue Sep 02 09:16:50 UTC 2014 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.