[DBAL-1163] Pagination issue with order by statement Created: 05/Mar/15  Updated: 05/Mar/15

Status: Open
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Vahe Shadunts Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: paginator, postgresql
Environment:

linux, PostgreSQL



 Description   

For example I have 2 entities (family, person) with ManyToOne(familyId) association in Person entity, and OneToMany(mappedBy="familyId") in Family Entity (Full class definitions are in the end of description)

And this is my DQL part

$query = $em -> createQuery('
select e0, e1 from TestPagingBundle:Family e0 join e0.people e1
order by e1.firstName asc
');
$query -> setMaxResults(2);

This is working perfectly when the ordered firstNames are from different families.

But the paginator class generates 3 queries, 1st for fetching count, second for id's 3rd is a general query for data.

This is the 2nd Query:

SELECT DISTINCT id0, first_name3
FROM (
SELECT f0_.id AS id0, f0_.name AS name1, p1_.id AS id2, p1_.first_name AS first_name3, p1_.last_name AS last_name4
FROM family f0_
INNER JOIN person p1_ ON f0_.id = p1_.family_id
ORDER BY p1_.first_name ASC
)dctrn_result
ORDER BY first_name3 ASC
LIMIT 2

So in the select statement in this query there are distinctly selected 2 fields, id and first_name.

And if we'll have 2 people in one family which names are Aaron and Abraham, this query result will be

id | name
-------------------
1 | Aaron
1 | Abraham
-------------------

So we have fetched only one id from families instead of 2, which we wanted to select.

Then the where statement of 3rd query will be where id in ( ? ) with params [1,1], and we are getting 1 Family instead of 2.

----------------
class Family

{ /** * @var integer * * @ORM\Column(name="id", type="integer") * @ORM\Id * @ORM\GeneratedValue(strategy="IDENTITY") */ private $id; /** * @var string * * @ORM\Column(name="name", type="string", length=256, nullable=true) */ private $name; /** * @OneToMany(targetEntity="Person", mappedBy="familyId") **/ private $people; }

class Person

{ /** * @var integer * * @ORM\Column(name="id", type="integer") * @ORM\Id * @ORM\GeneratedValue(strategy="IDENTITY") */ private $id; /** * @ManyToOne(targetEntity="Family") * @JoinColumn(name="family_id", referencedColumnName="id") **/ private $familyId; /** * @var string * * @ORM\Column(name="first_name", type="string", length=256, nullable=false) */ private $firstName; /** * @var string * * @ORM\Column(name="last_name", type="string", length=256, nullable=true) */ private $lastName; }




[DBAL-1162] [GH-811] BlobType without fopen & allow_url_fopen Created: 05/Mar/15  Updated: 05/Mar/15

Status: Open
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of ahurt2000:

Url: https://github.com/doctrine/dbal/pull/811

Message:

The allow_url_fopen parameter is disabled in many host providers by security. This commit introduces a small change to avoid the use of fopen function that this is affected by this parameter.






[DBAL-1161] [GH-810] Remove unneeded connect calls Created: 05/Mar/15  Updated: 05/Mar/15  Resolved: 05/Mar/15

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: 2.6
Security Level: All

Type: Improvement Priority: Minor
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: calls, connect, connection


 Description   

This issue is created automatically through a Github pull request on behalf of rosier:

Url: https://github.com/doctrine/dbal/pull/810

Message:

This PR removes a few unneeded calls to `Connection::connect()`



 Comments   
Comment by Doctrine Bot [ 05/Mar/15 ]

A related Github Pull-Request [GH-810] was merged:
https://github.com/doctrine/dbal/pull/810





[DBAL-1160] Oracle - UuidGenerator bug Created: 04/Mar/15  Updated: 04/Mar/15

Status: Open
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: 2.5.1
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Loïc Lavoie Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: dbal


 Description   

The current implementation of the generator strategy UUID for Oracle does not work with any of the version I have availalble (9-10-12)

When using it, the database raise an error the following error:

ORA-00923: FROM keyword not found where expected

The reason is that the statement return into the file DBAL\Plateform\OraclePlateform is missing the "FROM DUAL" (mandatory in oracle, you can't execute a query without a from).

Once this is fix, another error is raised:

ORA-01465: invalid hex number

The reason is that the getGuidExpression() return a binary result. Unfortunately, into the ORM part, it is not converted back in hex (using raw2hex).

My recommandation would be to simply return the following code in the OraclePlateform file:

    /**
     * {@inheritDoc}
     */
    public function getGuidExpression()
    {
        return 'RAWTOHEX(SYS_GUID()) FROM DUAL';
    }

This solution actually work on every plateform I've tested so far.






[DBAL-1159] [GH-809] travis: PHP 7.0 nightly added Created: 02/Mar/15  Updated: 02/Mar/15  Resolved: 02/Mar/15

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: 2.5.2
Security Level: All

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: php-7.0


 Description   

This issue is created automatically through a Github pull request on behalf of TomasVotruba:

Url: https://github.com/doctrine/dbal/pull/809

Message:

Also fixed standard to 2 spaces, that's used above



 Comments   
Comment by Doctrine Bot [ 02/Mar/15 ]

A related Github Pull-Request [GH-809] was assigned:
https://github.com/doctrine/dbal/pull/809

Comment by Doctrine Bot [ 02/Mar/15 ]

A related Github Pull-Request [GH-809] was merged:
https://github.com/doctrine/dbal/pull/809





[DBAL-1158] Using alias with order by and then applying a limit causes an SQL invalid column name error Created: 02/Mar/15  Updated: 02/Mar/15

Status: Open
Project: Doctrine DBAL
Component/s: Drivers, Platforms
Affects Version/s: 2.5.1
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Karl Dawson Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: dbal, sqlsrv
Environment:

Windows Server 2012 with SQL Server 2012. Using PHP sqlsrv extension and SQL Native Client 11.



 Description   

I was originally having a problem where aliases were not working with order by/group by. I switched to 2.5.1 and this fixed the issue; however this led to another one. When applying a limit to a query using an alias in conjunction with order by, it generates the following error:

SQLSTATE [42S22, 207]: [Microsoft][SQL Server Native Client 11.0][SQL Server]Invalid column name 'sclr1'

See the following example:

$qb = $this->createQueryBuilder('u');

$select = array(
'u.title',
'SUM(u.seconds) AS total_seconds',
);

$qb->select($select)
->groupBy('u.title')
->orderBy('total_seconds', 'DESC')
->setMaxResults(5);

return $qb->getQuery()->getResult();

This will return the above error, but removing the setMaxResults(5) from the query will allow it to work.






[DBAL-1157] [GH-808] Compatibility layer for PHP installations without PDO support - ticket D... Created: 28/Feb/15  Updated: 28/Feb/15

Status: Open
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of AZielinski:

Url: https://github.com/doctrine/dbal/pull/808

Message:

Even though DBAL currently offers non-PDO drivers, it depends on a number of PDO constants which renders it unusable if PHP was explicitly compiled without PDO. This PR is an attempt to shim PDO constants as stated in ticket DBAL-1156 (http://www.doctrine-project.org/jira/browse/DBAL-1156)



 Comments   
Comment by Doctrine Bot [ 28/Feb/15 ]

A related Github Pull-Request [GH-808] was assigned:
https://github.com/doctrine/dbal/pull/808





[DBAL-1156] Doctrine assumes that PDO is available Created: 23/Feb/15  Updated: 24/Feb/15

Status: Open
Project: Doctrine DBAL
Component/s: Drivers
Affects Version/s: 2.5.1
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Adam Zielinski Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: compatibility, dbal, mysqli, pdo


 Description   

`use PDO` and references to PDO class are seen in following files:
Connection.php
Statement.php
Cache/ArrayStatement.php
Cache/ResultCacheStatement.php
Driver/PDOConnection.php
Driver/Mysqli/MysqliStatement.php
Driver/OCI8/OCI8Statement.php
Driver/SQLSrv/SQLSrvStatement.php
Driver/Portability/Statement.php

It's all about using constants like PDO::FETCH_COLUMN. No actual methods are invoked, no objects are instantiated. This could be easily abstracted out to a class included in doctrine-dbal.

I stumbled upon this because I tried to use `mysqli` driver specifically because my installation of PHP is compiled with --disable-pdo.

As a quick & dirty workaround I included a file PDO.php with a shim, but it would be nice if Doctrine did not assume PDO is installed.

I am more than happy to prepare a pull request to fix it if you confirm this is something that needs attention.



 Comments   
Comment by Marco Pivetta [ 23/Feb/15 ]

Seems rather like a missing dependency in composer.json to me: we rely on PDO's APIs, and we're not really interested in polyfilling it when it's not available, as it's actually a lot of code to write for a little achievement :-\

Comment by Adam Zielinski [ 23/Feb/15 ]

Why provide non-PDO drivers then? In doctrine-dbal not a single method or object from PDO is used (aside of PDOConnection.php), it's all about accessing constants like PDO::PARAM_STR. This particular thing could be polyfilled very easily.

Comment by Marco Pivetta [ 23/Feb/15 ]

Those drivers work as long as PDO is also installed.

Comment by Adam Zielinski [ 23/Feb/15 ]

Sure they do, my point is that with minimal effort (that I offer to provide) those drivers could work without PDO as well. In fact that would make more sense - I can imagine that one of typical use cases for e.g. Mysqli driver is a situation where PDO cannot be used for some reason.

Correct me if I'm wrong, but I believe there is no real reason for doctrine-dbal to depend on PDO. Aside of accessing constants, PDO is only used by PDOConnection (which is only used by PDO-based drivers). PDO constants can be shimmed extremely easily.

Comment by Marco Pivetta [ 24/Feb/15 ]

Adam Zielinski if that's the minimal requirement, then a shim is fine





[DBAL-1155] [GH-807] Add support for named primary keys on SQL Server Created: 23/Feb/15  Updated: 23/Feb/15

Status: Open
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of zeroedin-bill:

Url: https://github.com/doctrine/dbal/pull/807

Message:

This PR adds support for named primary keys on SQL Server, and fixes 2 SQL generation tests that should generate named primary keys to do so.






[DBAL-1154] [GH-806] Fix broken functional test for SQL server Created: 23/Feb/15  Updated: 26/Feb/15  Resolved: 26/Feb/15

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: 2.6, 2.5.2
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: phpunit, sql-server, sqlsrv, testing, tests


 Description   

This issue is created automatically through a Github pull request on behalf of zeroedin-bill:

Url: https://github.com/doctrine/dbal/pull/806

Message:

Fixes default constraints test for SQL server – table name was wrong.



 Comments   
Comment by Doctrine Bot [ 26/Feb/15 ]

A related Github Pull-Request [GH-806] was merged:
https://github.com/doctrine/dbal/pull/806





[DBAL-1153] [GH-805] Allow symfony 3.0 components Created: 22/Feb/15  Updated: 22/Feb/15

Status: Open
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of nicolas-grekas:

Url: https://github.com/doctrine/dbal/pull/805

Message:

Tests should tell if any deprecated interfaces of Symfony are used. If not, then the bundle is defacto compatible with 3.0






[DBAL-1152] [GH-804] bugfix(Jira1077): Correction for parenthesis misbehavior on querylimit for sqlserver Created: 21/Feb/15  Updated: 21/Feb/15

Status: Open
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of folcoerr:

Url: https://github.com/doctrine/dbal/pull/804

Message:

bugfix(Jira1077): Correction for parenthesis misbehavior on querylimit for sqlserver

Correction added to production code
Test added for automated proof

Environment:
Windows 7/ Git Bash/ Sql Server
Test command line run : "./vendor/bin/phpunit -c ./sqlsrv.phpunit.xml --verbose ./tests/Doctrine/Tests/DBAL/Platforms/SQLServerPlatformTest.php"

Results:
![jira1077_dbalmaster_results](https://cloud.githubusercontent.com/assets/10148824/6312055/9d79743a-b96d-11e4-8842-5b9c649431a5.PNG)






[DBAL-1151] [GH-803] bugfix(Jira-1077): Correction for parenthesis misbehavior on querylimit for sql server Created: 21/Feb/15  Updated: 21/Feb/15

Status: Open
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of folcoerr:

Url: https://github.com/doctrine/dbal/pull/803

Message:

bugfix(Jira-1077): Correction for parenthesis misbehavior on querylimit for sql server

Correction added to production code
Test added for automated proof

Environment:
Windows 7/ Git Bash/ Sql Server
Test command line run : "./vendor/bin/phpunit -c ./phpunit.xml --verbose ./tests/Doctrine/Tests/DBAL/platforms/SqlServerPlatformTest.php"

Results:
![jira1077_dbal24_results](https://cloud.githubusercontent.com/assets/10148824/6312030/298f9c02-b96d-11e4-80a6-d1f1e5fcc9ef.PNG)






[DBAL-1150] [GH-802] Fix issue where schema diffs on sql server try and fail to drop nonexistent indexes Created: 19/Feb/15  Updated: 19/Feb/15

Status: Open
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of zeroedin-bill:

Url: https://github.com/doctrine/dbal/pull/802

Message:

When running a schema diff on SQL Server, the diff generated includes commands to drop indexes that don't exist. This doesn't fix that problem.

This patch works around the problem by changing sql generated like this:
```sql
IF EXISTS (SELECT * FROM sysobjects WHERE name = 'IDX_1234567890')
ALTER TABLE sometable DROP CONSTRAINT IDX_1234567890
ELSE
DROP INDEX IDX_1234567890 ON sometable
```

to this:

```sql
IF EXISTS (SELECT * FROM sysobjects WHERE name = 'IDX_1234567890')
ALTER TABLE sometable DROP CONSTRAINT IDX_1234567890
ELSE IF EXISTS (SELECT name FROM sysindexes WHERE name = 'IDX_1234567890')
DROP INDEX IDX_1234567890 ON sometable
```

Checking for the existence of the index to be dropped before trying to drop it.

The root of the problem, however, is that when the "from" schema is hydrated from schema-details via Table::__construct, a unique index is added for @JoinColumns that are flagged as unique. This also happens for joined table inheritance child tables.






[DBAL-1149] [GH-801] Add deprecated annotation to renameColumn method Created: 10/Feb/15  Updated: 10/Feb/15  Resolved: 10/Feb/15

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Documentation Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Invalid Votes: 0
Labels: deprecated, rename-column, schema, table


 Description   

This issue is created automatically through a Github pull request on behalf of driesvints:

Url: https://github.com/doctrine/dbal/pull/801

Message:

I added the deprecated annotation to warn a user that the method isn't working anymore. This will allow a dev to spot the deprecated method before he actually attempts to use it.

![screen shot 2015-02-10 at 09 55 50](https://cloud.githubusercontent.com/assets/594614/6124164/646f5f8e-b10b-11e4-9098-e1cb999d720d.png)

Should there be some comment added or perhaps a referring to the exception message?



 Comments   
Comment by Doctrine Bot [ 10/Feb/15 ]

A related Github Pull-Request [GH-801] was assigned:
https://github.com/doctrine/dbal/pull/801

Comment by Doctrine Bot [ 10/Feb/15 ]

A related Github Pull-Request [GH-801] was closed:
https://github.com/doctrine/dbal/pull/801





[DBAL-1148] [GH-800] Add a Gitter chat badge to README.md Created: 09/Feb/15  Updated: 09/Feb/15  Resolved: 09/Feb/15

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of gitter-badger:

Url: https://github.com/doctrine/dbal/pull/800

Message:

      1. doctrine/dbal now has a Chat Room on Gitter

@jwage has just created a chat room. You can visit it here: https://gitter.im/doctrine/dbal(https://gitter.im/doctrine/dbal?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&content=body_link).

This pull-request adds this badge to your README.md:

[![Gitter](https://badges.gitter.im/Join%20Chat.svg)](https://gitter.im/doctrine/dbal?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=body_badge)

If my aim is a little off, please [let me know](https://github.com/gitterHQ/readme-badger/issues).

Happy chatting.

PS: [Click here](https://gitter.im/settings/badger/opt-out) if you would prefer not to receive automatic pull-requests from Gitter in future.



 Comments   
Comment by Doctrine Bot [ 09/Feb/15 ]

A related Github Pull-Request [GH-800] was closed:
https://github.com/doctrine/dbal/pull/800

Comment by Doctrine Bot [ 09/Feb/15 ]

A related Github Pull-Request [GH-800] was assigned:
https://github.com/doctrine/dbal/pull/800





[DBAL-1147] [GH-799] Added option to set connect_timeout setting in PDOPgSql dsn Created: 09/Feb/15  Updated: 09/Feb/15  Resolved: 09/Feb/15

Status: Resolved
Project: Doctrine DBAL
Component/s: Drivers
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Invalid Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of bashofmann:

Url: https://github.com/doctrine/dbal/pull/799

Message:

See http://php.net/manual/en/function.pg-connect.php



 Comments   
Comment by Doctrine Bot [ 09/Feb/15 ]

A related Github Pull-Request [GH-799] was closed:
https://github.com/doctrine/dbal/pull/799





[DBAL-1146] [GH-798] Add application_name to PostgreSQL driver Created: 04/Feb/15  Updated: 04/Feb/15

Status: Open
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of davividal:

Url: https://github.com/doctrine/dbal/pull/798

Message:

PostgreSQL allows the user to set the application_name is connecting
to database. It is useful for monitoring purposes.
Currently one could just manually add 'application_name=foo' to DSN,
but having a parameter eases setting it using DoctrineBundle.






[DBAL-1145] Add support for temporary tables Created: 01/Feb/15  Updated: 01/Feb/15

Status: Open
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: New Feature Priority: Major
Reporter: Jeroen De Dauw Assignee: Steve Müller
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Right now there is no real support for creating temporary tables. Having an interface that takes a Table and constructs temporary table creation sql from it would solve this.

Suggested by beberlei:

$table = new Table();
$table->addOption('temporary', true);
$platform->getCreateTableSQL( $table );






[DBAL-1144] [GH-797] unsigned boolean Created: 31/Jan/15  Updated: 06/Mar/15

Status: Open
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of liutec:

Url: https://github.com/doctrine/dbal/pull/797

Message:



 Comments   
Comment by Doctrine Bot [ 06/Mar/15 ]

A related Github Pull-Request [GH-797] was closed:
https://github.com/doctrine/dbal/pull/797





[DBAL-1143]  PostgreSQL PostgreSQL94 Created: 31/Jan/15  Updated: 31/Jan/15

Status: Open
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Task Priority: Minor
Reporter: Konstantin Nizhinskiy Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: postgresql


 Description   

Add new type jsonb
doc:
http://info.enterprisedb.com/rs/enterprisedb/images/EDB_White_Paper_Using_the_NoSQL_Features_in_Postgres.pdf






[DBAL-1142] [GH-796] Add tsvector type support in PostgreSQL Platform Created: 31/Jan/15  Updated: 10/Feb/15  Resolved: 10/Feb/15

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: None
Fix Version/s: 2.6
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: mapping, pgsql, postgresql, tsvector, type

Issue Links:
Duplicate
is duplicated by DBAL-1141 [GH-795] Add tsvector type support in... Resolved

 Description   

This issue is created automatically through a Github pull request on behalf of believer-ufa:

Url: https://github.com/doctrine/dbal/pull/796

Message:

This conversation continued in this request: https://github.com/doctrine/dbal/pull/795

I created test case and changed field type to "text". Test passes)



 Comments   
Comment by Doctrine Bot [ 01/Feb/15 ]

A related Github Pull-Request [GH-796] was assigned:
https://github.com/doctrine/dbal/pull/796

Comment by Doctrine Bot [ 10/Feb/15 ]

A related Github Pull-Request [GH-796] was merged:
https://github.com/doctrine/dbal/pull/796

Comment by Doctrine Bot [ 10/Feb/15 ]

A related Github Pull-Request [GH-795] was closed:
https://github.com/doctrine/dbal/pull/795





[DBAL-1141] [GH-795] Add tsvector type support in PostgreSQL Platform Created: 31/Jan/15  Updated: 10/Feb/15  Resolved: 10/Feb/15

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Duplicate Votes: 0
Labels: mapping, pgsql, postgresql, tsvector, type

Issue Links:
Duplicate
duplicates DBAL-1142 [GH-796] Add tsvector type support in... Resolved

 Description   

This issue is created automatically through a Github pull request on behalf of believer-ufa:

Url: https://github.com/doctrine/dbal/pull/795

Message:

Just one simple string. Maybe add this to code?



 Comments   
Comment by Doctrine Bot [ 10/Feb/15 ]

A related Github Pull-Request [GH-795] was closed:
https://github.com/doctrine/dbal/pull/795





[DBAL-1140] [GH-794] Update QueryBuilderTest.php Created: 30/Jan/15  Updated: 05/Mar/15  Resolved: 05/Mar/15

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Improvement Priority: Minor
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Invalid Votes: 0
Labels: duplicate, query-builder, table-alias


 Description   

This issue is created automatically through a Github pull request on behalf of jarekj:

Url: https://github.com/doctrine/dbal/pull/794

Message:

just testing if tests will fail



 Comments   
Comment by Doctrine Bot [ 05/Mar/15 ]

A related Github Pull-Request [GH-794] was closed:
https://github.com/doctrine/dbal/pull/794





[DBAL-1139] [GH-793] fix SequenceName for Oracle Created: 30/Jan/15  Updated: 30/Jan/15

Status: Open
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of Gemorroj:

Url: https://github.com/doctrine/dbal/pull/793

Message:

I want to use a new feature, specify the oracle IDENITY generator (http://www.doctrine-project.org/jira/browse/DDC-2875) . But after inserting a new row, doctrine causes the wrong sequence to find out the id of the inserted row. My problem is solved by adding processing the column name.






[DBAL-1138] [GH-792] getSQLForJoins - infinite recursion if join alias is not unique Created: 30/Jan/15  Updated: 30/Jan/15  Resolved: 30/Jan/15

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Duplicate Votes: 0
Labels: None

Issue Links:
Duplicate
duplicates DBAL-1137 Infinite recursion on non-unique tabl... Resolved

 Description   

This issue is created automatically through a Github pull request on behalf of jarekj:

Url: https://github.com/doctrine/dbal/pull/792

Message:

fix for exception message



 Comments   
Comment by Doctrine Bot [ 30/Jan/15 ]

A related Github Pull-Request [GH-792] was closed:
https://github.com/doctrine/dbal/pull/792





[DBAL-1137] Infinite recursion on non-unique table/join alias in QueryBuilder Created: 30/Jan/15  Updated: 30/Jan/15  Resolved: 30/Jan/15

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: 2.6, 2.4.5, 2.5.2
Security Level: All

Type: Bug Priority: Major
Reporter: Steve Müller Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: alias, duplicate, infinite, non-unique, querybuilder, recursion

Issue Links:
Duplicate
is duplicated by DBAL-1138 [GH-792] getSQLForJoins - infinite re... Resolved
Reference
is referenced by DBAL-1136 [GH-791] Update QueryBuilderTest.php Resolved

 Description   

The QueryBuilder runs into an infinite recursion when using duplicate table aliases for table and/or join clauses:

$qb->select('a.id, b.id')
    ->from('table_a', 'a')
    ->join('a', 'table_b', 'b', 'a.fk_b = b.id')
    ->join('a', 'table_b', 'b', 'a.fk_b = b.id')
    ->join('b', 'table_a', 'a', 'a.fk_b = b.id');

Non-unique table aliases should be detected and an appropriate exception should be thrown instead.






[DBAL-1136] [GH-791] Update QueryBuilderTest.php Created: 30/Jan/15  Updated: 30/Jan/15  Resolved: 30/Jan/15

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Incomplete Votes: 0
Labels: alias, duplicate, infinite, non-unique, querybuilder, recursion

Issue Links:
Reference
relates to DBAL-1137 Infinite recursion on non-unique tabl... Resolved

 Description   

This issue is created automatically through a Github pull request on behalf of jarekj:

Url: https://github.com/doctrine/dbal/pull/791

Message:

test shows out of memory



 Comments   
Comment by Doctrine Bot [ 30/Jan/15 ]

A related Github Pull-Request [GH-791] was closed:
https://github.com/doctrine/dbal/pull/791





[DBAL-1135] [GH-789] Fix when finding arrays of binary strings Created: 28/Jan/15  Updated: 29/Jan/15

Status: Open
Project: Doctrine DBAL
Component/s: Drivers
Affects Version/s: None
Fix Version/s: 2.4, 2.5, 2.6
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Unresolved Votes: 0
Labels: array, binary, expansion, lob, parameter, sqlparserutils


 Description   

This issue is created automatically through a Github pull request on behalf of cerealean:

Url: https://github.com/doctrine/dbal/pull/789

Message:

What the problem was
-------------------------
When using the ORM findBy() method to select data in a binary column (compared against an array of binary strings), I would get exceptions. Code example:

```php
/**

  • @param string[] $email_addresses Encrypted email addresses
  • @return \Project\Entity\EmailAddresses[]
    */
    public function retrieveEmailAddressEntities(array $email_addresses) { return $this->repository->findBy(['EmailAddress' => $email_addresses]); }

    ```

When I would only search for one binary string, however, everything would work correctly. I noticed I was getting a PHP Notice for array to string conversion in my error log:

```
PHP Notice: Array to string conversion in/var/www/html/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOStatement.php on line 91
```

In my MySQL table, the column is a varbinary(255) and the ORM entity was marked as type "binary".

How I fixed
--------------
I noticed that the `$type` in `SQLParserUtils::expandListParameters` was marking the type as 103. When this method was checking array types, it was not checking for binary strings. By simply adding the extra check for type 103 in this method, everything started working properly. Line comments below.

Extra
------
This worked to fix it for me and I haven't noticed any side effects of this, however I have not extensively tested all features. If there are any problems with this please let me know.

Specific file commit comments:
--------------------------------------
Connection.php

  • Added constant PARAM_LOB_ARRAY for binary

SQLParserUtils.php

  • Added check to see if the array type is binary
  • Changed the way that the foreach checked if the type was not equal to int, string, or binary





[DBAL-1134] [GH-788] Improved failure resilience for array type Created: 26/Jan/15  Updated: 26/Jan/15  Resolved: 26/Jan/15

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: array, array-type, exceptions, type, type-conversion, type-safety, validator


 Description   

This issue is created automatically through a Github pull request on behalf of garwat82:

Url: https://github.com/doctrine/dbal/pull/788

Message:

The array type is the only one that throws an error if the value can't be decoded and that causes problems if the database column is empty or invalid. The patch adjusts the behavior to the rest of the implemented types.



 Comments   
Comment by Doctrine Bot [ 26/Jan/15 ]

A related Github Pull-Request [GH-788] was closed:
https://github.com/doctrine/dbal/pull/788

Comment by Doctrine Bot [ 26/Jan/15 ]

A related Github Pull-Request [GH-788] was assigned:
https://github.com/doctrine/dbal/pull/788





[DBAL-1133] [GH-787] Add left-over console file Created: 26/Jan/15  Updated: 26/Jan/15  Resolved: 26/Jan/15

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: 2.6
Security Level: All

Type: Improvement Priority: Trivial
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: binary, composer, console, tools


 Description   

This issue is created automatically through a Github pull request on behalf of t0xicCode:

Url: https://github.com/doctrine/dbal/pull/787

Message:

`bin/doctrine-dbal` includes `bin/doctrine-dbal.php`, but the later is not symlinked to the `vendor/bin` directory of projects as it is not declared in composer.json. This PR declares the file as a vendor binary.



 Comments   
Comment by Doctrine Bot [ 26/Jan/15 ]

A related Github Pull-Request [GH-787] was assigned:
https://github.com/doctrine/dbal/pull/787

Comment by Doctrine Bot [ 26/Jan/15 ]

A related Github Pull-Request [GH-787] was merged:
https://github.com/doctrine/dbal/pull/787





[DBAL-1132] [GH-786] Fix removing autoincrement column from a primary key Created: 26/Jan/15  Updated: 10/Feb/15  Resolved: 10/Feb/15

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: None
Fix Version/s: 2.6, 2.4.5, 2.5.2
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: alter-table, autoincrement, mysql, primary-key

Issue Links:
Reference
relates to DBAL-464 MySQL fails when try to drop a primar... Resolved

 Description   

This issue is created automatically through a Github pull request on behalf of andig:

Url: https://github.com/doctrine/dbal/pull/786

Message:

https://github.com/doctrine/dbal/pull/430 is only a partial fix for DBAL-464. This adds treating autoincrement columns that get removed when altering a primary key.



 Comments   
Comment by Doctrine Bot [ 01/Feb/15 ]

A related Github Pull-Request [GH-786] was assigned:
https://github.com/doctrine/dbal/pull/786

Comment by Doctrine Bot [ 10/Feb/15 ]

A related Github Pull-Request [GH-786] was merged:
https://github.com/doctrine/dbal/pull/786





[DBAL-1131] [GH-785] Handle default values for datetime/datetimetz columns in PostgreSQL Created: 25/Jan/15  Updated: 25/Jan/15

Status: Open
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of sarcher:

Url: https://github.com/doctrine/dbal/pull/785

Message:

(This was originally in #670 but am re-submitting due to a busted merge)

When dealing with legacy schema it would be nice to be able to map default values and not have the schema spit out ALTER statements each time. This works correctly today for basic integer and string columns, but does not handle columns with special types such as boolean or datetime.

For example, the following statement:

`ALTER TABLE test_table ALTER test_column SET DEFAULT CURRENT_TIMESTAMP;`

Results in a column definition like:

`test_column | timestamp with time zone | not null default now()`

However, repeating the same schema generation will result in the same ALTER statement each time, because it will always detect that the default value has changed. The same is true for boolean columns.

This simple change prevents this situation from happening and correctly detects that the column default has not changed. It is specific to PostgreSQL.






[DBAL-1130] [GH-784] "Breaking" a test temporarily to show that it's not doing what is expect... Created: 23/Jan/15  Updated: 23/Jan/15

Status: Open
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of weaverryan:

Url: https://github.com/doctrine/dbal/pull/784

Message:

Hi guys!

This is not meant to be merged, at least not yet. The test added in #691 is flawed. It's failing NOT because there is an exception when trying to use a closed connection (in fact, if the connection is closed, it simply re-opens), but instead, the exception is:

>
Access denied for user 'root'@'localhost' (using password: YES)

The tests should show this. The reason is that we're using connection parameters at the top of this class (https://github.com/doctrine/dbal/blob/master/tests/Doctrine/Tests/DBAL/ConnectionTest.php#L19) that, until now, were never used to actually connect to the database. But now, they are being used to connect to the database, but they're incorrect - they should be pulling from `TestUtil`.

So, this test needs to be fixed or removed.

Thanks!






[DBAL-1129] [GH-783] Fixes issue (DBAL-1057) use default platform when not connected Created: 23/Jan/15  Updated: 29/Jan/15

Status: Open
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of weaverryan:

Url: https://github.com/doctrine/dbal/pull/783

Message:

Hi guys!

This is a fix for http://www.doctrine-project.org/jira/browse/DBAL-1057. It leaves the ability to set the platform and platform version from sha: 3176f51d1426022d305c6531a9b9bc93a868bddd, but does not try to connect if we're not already connected. This is consistent with the previous behavior (again see the linked sha) - before there was never a connection made to determine the platform.

The alternate solution is to connect, but surround this by a try-catch (`PDOException`, `DriverException`, `Exception`?) and return `null`. in case we have some situation where the database isn't created or the connection information is wrong.

I know this issue is causing a lot of problems around my world (I ran into myself yesterday), so thanks in advance for the attention.

Thanks!



 Comments   
Comment by Doctrine Bot [ 23/Jan/15 ]

A related Github Pull-Request [GH-783] was closed:
https://github.com/doctrine/dbal/pull/783

Comment by Doctrine Bot [ 23/Jan/15 ]

A related Github Pull-Request [GH-783] was reopened:
https://github.com/doctrine/dbal/pull/783

Comment by Doctrine Bot [ 29/Jan/15 ]

A related Github Pull-Request [GH-783] was closed:
https://github.com/doctrine/dbal/pull/783





[DBAL-1128] [GH-782] Fix: SQLite offset with no limit support Created: 23/Jan/15  Updated: 24/Jan/15  Resolved: 24/Jan/15

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: 2.3.5, 2.4.4, 2.5.1
Fix Version/s: 2.6, 2.4.5, 2.5.2
Security Level: All

Type: Bug Priority: Critical
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: limit, offset, paginator, select, sqlite, syntax


 Description   

This issue is created automatically through a Github pull request on behalf of Ocramius:

Url: https://github.com/doctrine/dbal/pull/782

Message:

Required for doctrine/doctrine2#1280

This just slipped through.

Should be merged into 2.4, 2.5 and 2.6



 Comments   
Comment by Doctrine Bot [ 23/Jan/15 ]

A related Github Pull-Request [GH-782] was assigned:
https://github.com/doctrine/dbal/pull/782

Comment by Doctrine Bot [ 24/Jan/15 ]

A related Github Pull-Request [GH-782] was assigned:
https://github.com/doctrine/dbal/pull/782

Comment by Doctrine Bot [ 24/Jan/15 ]

A related Github Pull-Request [GH-782] was unassigned:
https://github.com/doctrine/dbal/pull/782

Comment by Doctrine Bot [ 24/Jan/15 ]

A related Github Pull-Request [GH-782] was merged:
https://github.com/doctrine/dbal/pull/782





[DBAL-1127] [GH-781] Call detectDatabasePlatform only once Created: 22/Jan/15  Updated: 22/Jan/15

Status: Open
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of rosier:

Url: https://github.com/doctrine/dbal/pull/781

Message:

Database platform detection is triggered twice if `Doctrine/DBAL/Connection::getDatabasePlatform()` is called before `Doctrine/DBAL/Connection::connect()`






[DBAL-1126] Amazon SimpleDB/DynamoDB Support Created: 21/Jan/15  Updated: 21/Jan/15

Status: Open
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: New Feature Priority: Major
Reporter: Bo Zhou Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Hello

Would you please to tell me if there is any plan to support ORM for Amazon SimpleDB/DynamoDB ? Thanks !



 Comments   
Comment by Marco Pivetta [ 21/Jan/15 ]

I don't see join support in AWS DynamoDB, therefore I don't see how support from our side can be provided





[DBAL-1125] [GH-780] Add autoload to composer.json Created: 20/Jan/15  Updated: 21/Jan/15  Resolved: 21/Jan/15

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: 2.0
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: autoloader, composer


 Description   

This issue is created automatically through a Github pull request on behalf of pgddevil:

Url: https://github.com/doctrine/dbal/pull/780

Message:



 Comments   
Comment by Doctrine Bot [ 21/Jan/15 ]

A related Github Pull-Request [GH-780] was closed:
https://github.com/doctrine/dbal/pull/780





[DBAL-1124] License notes whis porting of classes Created: 19/Jan/15  Updated: 20/Jan/15

Status: Open
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Task Priority: Minor
Reporter: Vladimir Khramov Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

I ported SQLParserUtils to zephir language for Phalcon 2 framework and used modified php tests for this class.

Phalcon licended by New BSD. Now I used default phalcon templates for files:
https://github.com/quantum13/cphalcon/blob/bind_array/phalcon/db/utils/sqlparser.zep
https://github.com/quantum13/cphalcon/blob/bind_array/tests/unit/Phalcon/Db/Utils/SQLParserTest.php

Please say, what I should to add to this files. Should I to add MIT license text to list of phalcon licenses?



 Comments   
Comment by Marco Pivetta [ 19/Jan/15 ]

The license clearly states:

Permission is hereby granted, free of charge, to any person obtaining a copy of
this software and associated documentation files (the "Software"), to deal in
the Software without restriction, including without limitation the rights to
use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies
of the Software, and to permit persons to whom the Software is furnished to do
so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

You need to copy the LICENSE from https://github.com/doctrine/doctrine2/blob/2418f8f5e661c653e4b13cd433d569ece7318f62/LICENSE at least into the derived files, and keep a reference to the original author there.

Other than that, MIT, BSD-2-Clause and BSD-3-Clause are compatible.





[DBAL-1123] [GH-779] Initialize database schema only once per PHPUnit run Created: 18/Jan/15  Updated: 18/Jan/15  Resolved: 18/Jan/15

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: 2.6
Security Level: All

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: performance, phpunit, testsuite


 Description   

This issue is created automatically through a Github pull request on behalf of deeky666:

Url: https://github.com/doctrine/dbal/pull/779

Message:

Currently the PHPUnit test suite recreates the database schema on each invocation of `TestUtil::getConnection()` which is highly inefficient and costly concerning performance, especially on platforms where schema recreation consumes a lot of time.
With this patch the database schema is initilaized once per PHPUnit run, increasing overall test suite runtime significantly.
For example using SQL Anywhere, database creation takes about 4-5 seconds which results in a complete test suite runtime of several minutes. With this patch the complete test suite runs in about 12-15 seconds *!*.



 Comments   
Comment by Doctrine Bot [ 18/Jan/15 ]

A related Github Pull-Request [GH-779] was assigned:
https://github.com/doctrine/dbal/pull/779

Comment by Doctrine Bot [ 18/Jan/15 ]

A related Github Pull-Request [GH-779] was merged:
https://github.com/doctrine/dbal/pull/779





[DBAL-1122] [GH-778] Cleanup PHPUnit test suite bootstrap Created: 18/Jan/15  Updated: 18/Jan/15  Resolved: 18/Jan/15

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: 2.6
Security Level: All

Type: Improvement Priority: Minor
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: bootstrap, phpunit, testing


 Description   

This issue is created automatically through a Github pull request on behalf of deeky666:

Url: https://github.com/doctrine/dbal/pull/778

Message:

Removes `require_once` statements leftovers in PHPUnit test classes in favour of properly bootstrapping via PHPUnit config files.



 Comments   
Comment by Doctrine Bot [ 18/Jan/15 ]

A related Github Pull-Request [GH-778] was assigned:
https://github.com/doctrine/dbal/pull/778

Comment by Doctrine Bot [ 18/Jan/15 ]

A related Github Pull-Request [GH-778] was merged:
https://github.com/doctrine/dbal/pull/778





[DBAL-1121] [GH-777] Make host and server connection parameters optional for sqlanywhere driver Created: 18/Jan/15  Updated: 18/Jan/15  Resolved: 18/Jan/15

Status: Resolved
Project: Doctrine DBAL
Component/s: Drivers
Affects Version/s: 2.5
Fix Version/s: 2.6, 2.5.2
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: connection, driver, host, parameters, server, sqlanywhere


 Description   

This issue is created automatically through a Github pull request on behalf of deeky666:

Url: https://github.com/doctrine/dbal/pull/777

Message:

This patch makes it possible to connect to a SQL Anywhere database without having to specify `host` and/or `server` connection parameter.
The original assumption that the `server` parameter is necessary to connect to the database was wrong. It is only required if the host is running multiple named server instances and a specific instance should be connected to.
Also if the `host` parameter is not specified, it will default to `localhost` now.
The `LINKS` DSN parameter was replaced by the simpler and encouraged `HOST` parameter as the `LINKS` parameter is only required if you want to pass specific TCP/IP options.



 Comments   
Comment by Doctrine Bot [ 18/Jan/15 ]

A related Github Pull-Request [GH-777] was assigned:
https://github.com/doctrine/dbal/pull/777

Comment by Doctrine Bot [ 18/Jan/15 ]

A related Github Pull-Request [GH-777] was merged:
https://github.com/doctrine/dbal/pull/777





[DBAL-1120] [GH-776] Don't throw an exception during database platform guessing Created: 16/Jan/15  Updated: 19/Jan/15  Resolved: 19/Jan/15

Status: Resolved
Project: Doctrine DBAL
Component/s: Drivers
Affects Version/s: 2.5, 2.5.1
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: connection, detection, platform


 Description   

This issue is created automatically through a Github pull request on behalf of rosier:

Url: https://github.com/doctrine/dbal/pull/776

Message:

Fallback to the "default" database platform if connecting to the database fails.

Fixes https://github.com/symfony/symfony-standard/issues/748



 Comments   
Comment by Doctrine Bot [ 16/Jan/15 ]

A related Github Pull-Request [GH-776] was assigned:
https://github.com/doctrine/dbal/pull/776





[DBAL-1119] [GH-775] fix diffColumn in text length is different Created: 16/Jan/15  Updated: 16/Jan/15  Resolved: 16/Jan/15

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Invalid Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of arima-ryunosuke:

Url: https://github.com/doctrine/dbal/pull/775

Message:

Because mysql has multiple TEXT types.

```
$column1 = new Column('clobfield1', Type::getType('text'), array('Length' => 128));
$column2 = new Column('clobfield1', Type::getType('text'), array('Length' => 65536));

$platform = new MySqlPlatform();
var_dump($platform->getClobTypeDeclarationSQL($column1->toArray()));// this is "TINYTEXT"
var_dump($platform->getClobTypeDeclarationSQL($column2->toArray()));// this is "MEDIUMTEXT"

$c = new Comparator();
var_dump($c->diffColumn($column1, $column2));// this is empty!
```



 Comments   
Comment by Doctrine Bot [ 16/Jan/15 ]

A related Github Pull-Request [GH-775] was closed:
https://github.com/doctrine/dbal/pull/775

Comment by Doctrine Bot [ 16/Jan/15 ]

A related Github Pull-Request [GH-775] was assigned:
https://github.com/doctrine/dbal/pull/775





[DBAL-1118] Schema does not create autoincrement keys for MySQL Created: 15/Jan/15  Updated: 16/Jan/15  Resolved: 16/Jan/15

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

Type: Bug Priority: Major
Reporter: Gabriel Birke Assignee: Benjamin Eberlei
Resolution: Cannot Reproduce Votes: 0
Labels: None


 Description   

There seems to be no way to generate an autoincrementing primary key for MySQL with the the Schema class:

    $schema = new \Doctrine\DBAL\Schema\Schema;
    $table = $schema->createTable("foo");
    $table->addColumn('id', "integer", array("unsigned" => true);
    $table->setPrimaryKey(array("id"));
    $connectionParams = ["url" => "mysql://user:password@localhost/mydb"];
    $conn = \Doctrine\DBAL\DriverManager::getConnection($connectionParams, $config);
    $queries = $schema->toSql($conn->getSchemaManager()->getDatabasePlatform());
    foreach ($queries as $q) {
            echo "$q\n";
            $conn->exec($q);
     }

creates a table without autoincrementing keys. The SQL generated is as follows:

CREATE TABLE foo (id INT UNSIGNED NOT NULL, PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB

When I change the definition to

$table->addColumn('id', "integer", array("unsigned" => true, "autoincrement" => true));

instead, I get the following error:

SQLSTATE[42000]: Syntax error or access violation: 1075 Incorrect table definition; there can be only one auto column and it must be defined as a key.

and the following SQL:

CREATE TABLE foo (id INT UNSIGNED AUTO_INCREMENT NOT NULL, PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB

If there is a way to achieve this, please update the documentation.



 Comments   
Comment by Steve Müller [ 15/Jan/15 ]

This looks like a usage error. Can you please provide more information on how you create the table in the database? Those code snippets do show how you actually create the table in the database. Maybe also the executed SQL would help.

Comment by Gabriel Birke [ 15/Jan/15 ]

I've updated the code example. I can run the whole example locally and it generates a table "foo" with column "id" that is a primary key without autoincrement. Tried on two computers. Probably a usage error, but what am I missing?

Comment by Steve Müller [ 16/Jan/15 ]

Gabriel Birke thanks for the additional information. However we also need the exact SQL statements that are generated by $schema->toSql($conn->getSchemaManager()->getDatabasePlatform());
Thank you. Also are you using DBAL 2.5.1 (according to the ticket information)?

Comment by Steve Müller [ 16/Jan/15 ]

And please remember to gather the SQL when using autoincrement => true

Comment by Gabriel Birke [ 16/Jan/15 ]

Well, at least for my small test script it works now (it did not yesterday, but I don't know why).

Comment by Steve Müller [ 16/Jan/15 ]

Gabriel Birke both SQL statements are totally valid and expected to be generated this way. Also tried them out locally and they work perfectly. I guess it was a usage mistake somehow then. If it's working for you now I would like to close the issue

Comment by Steve Müller [ 16/Jan/15 ]

Ah you did already, thanks!





[DBAL-1117] id names not quoted on create in MySQL Created: 14/Jan/15  Updated: 14/Jan/15

Status: Open
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: 2.5.1
Fix Version/s: None
Security Level: All

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

Ubuntu 14.04, MySQL 5.5, MySQLi driver



 Description   

Having the following line in the xml configurations will cause creation to fail with a sql error because group is a key word.
<id name="group" association-key="true"/>






[DBAL-1116] [GH-774] Added SET and ENUM types for MySQL and fix issue with schema update tool Created: 14/Jan/15  Updated: 14/Jan/15  Resolved: 14/Jan/15

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: New Feature Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: ddl, enum, mysql, set, type

Issue Links:
Dependency
is required for DBAL-4 missing column type "enum" Resolved
Reference
relates to DBAL-89 MySqlPlatform does not handle enum a... Resolved

 Description   

This issue is created automatically through a Github pull request on behalf of dimak08:

Url: https://github.com/doctrine/dbal/pull/774

Message:

Set and Enum data types are one of the most popular. However, addition of these data types in the project creates a problem when updating of the database structure.



 Comments   
Comment by Doctrine Bot [ 14/Jan/15 ]

A related Github Pull-Request [GH-774] was assigned:
https://github.com/doctrine/dbal/pull/774

Comment by Doctrine Bot [ 14/Jan/15 ]

A related Github Pull-Request [GH-774] was closed:
https://github.com/doctrine/dbal/pull/774

Comment by Marco Pivetta [ 14/Jan/15 ]

See http://stackoverflow.com/a/9057352/347063

ENUM and SET are non-portable types that will not be implemented by the DBAL due to the complexity behind their handling.





[DBAL-1115] [GH-773] Fix quoted identifiers for database creation SQL on SQL Anywhere Created: 13/Jan/15  Updated: 28/Jan/15  Resolved: 28/Jan/15

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: 2.5
Fix Version/s: 2.6, 2.5.2
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: create-database, ddl, drop-database, identifier, quotation, sqlanywhere


 Description   

This issue is created automatically through a Github pull request on behalf of deeky666:

Url: https://github.com/doctrine/dbal/pull/773

Message:

In SQL Anywhere the statements `CREATE DATABASE`, `DROP DATABASE`, `START DATABASE`, `STOP DATABASE` always take unquoted identifiers.
This PR ensures given identifiers are always passed unquoted to the generated SQL.
This issue was discovered by using DoctrineBundle's `database:create` and `database:drop` commands which always quote the database identifiers.

```bash
$ php app/console doctrine:database:create
Could not create database for connection named "symfony"
An exception occurred while executing 'START DATABASE '"symfony"' AUTOSTOP OFF':

SQLSTATE [00000] [-82] Angegebene Datenbank konnte nicht gestartet werden: Illegal character in database alias.
```



 Comments   
Comment by Doctrine Bot [ 13/Jan/15 ]

A related Github Pull-Request [GH-773] was assigned:
https://github.com/doctrine/dbal/pull/773

Comment by Doctrine Bot [ 28/Jan/15 ]

A related Github Pull-Request [GH-773] was merged:
https://github.com/doctrine/dbal/pull/773





[DBAL-1114] Problem with drop database on PostgreSQL Created: 13/Jan/15  Updated: 13/Jan/15

Status: Open
Project: Doctrine DBAL
Component/s: None
Affects Version/s: 2.4.4
Fix Version/s: None
Security Level: All

Type: Task Priority: Minor
Reporter: Marcin Zawadzki Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None

Issue Links:
Reference
relates to DBAL-1093 [GH-757] Fix creating and dropping da... Resolved

 Description   

Hello,

After upgrading doctrine/dbal from version v2.4.3 to v2.4.4 I couldn't drop database by command line with zero open connections.

Example:

./app/console doctrine:database:drop --force
Could not drop database for connection named "test"
An exception occurred while executing 'DROP DATABASE "test"':

SQLSTATE[55006]: Object in use: 7 ERROR: cannot drop the currently open database

details:
• PostgreSQL 9.2.4
• PHP 5.5.10

Any suggestions or workarounds for this issue?

Thank you



 Comments   
Comment by Steve Müller [ 13/Jan/15 ]

Issue introduced in DBAL-1093, to be fixed in DoctrineBundle. PR provided: https://github.com/doctrine/DoctrineBundle/pull/368





[DBAL-1113] [GH-772] Problem with drop database on PostgreSQL Created: 13/Jan/15  Updated: 13/Jan/15  Resolved: 13/Jan/15

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of Cinal:

Url: https://github.com/doctrine/dbal/pull/772

Message:

Hello,

After upgrading doctrine/dbal from version v2.4.3 to v2.4.4 I couldn't drop database with zero open connections.

Example:

./app/console doctrine:database:drop --force
Could not drop database for connection named "test"
An exception occurred while executing 'DROP DATABASE "test"':

SQLSTATE[55006]: Object in use: 7 ERROR: cannot drop the currently open database

details:
��� PostgreSQL 9.2.4
��� PHP 5.5.10

Any suggestions or workarounds for this issue.

Thank you



 Comments   
Comment by Doctrine Bot [ 13/Jan/15 ]

A related Github Pull-Request [GH-772] was closed:
https://github.com/doctrine/dbal/pull/772

Comment by Doctrine Bot [ 13/Jan/15 ]

A related Github Pull-Request [GH-772] was assigned:
https://github.com/doctrine/dbal/pull/772





[DBAL-1112] sqlite - Insert statement with keyword as column name raises sql-error Created: 12/Jan/15  Updated: 12/Jan/15  Resolved: 12/Jan/15

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: 2.5
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Florian Semm Assignee: Benjamin Eberlei
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

We are using a sqlite db in our unit tests. During fixtures-load a error occurs:

[Doctrine\DBAL\Exception\SyntaxErrorException]
An exception occurred while executing 'INSERT INTO state (name, type, group) VALUES (?, ?, ?)':
SQLSTATE[HY000]: General error: 1 near "group": syntax error

We are using for all queries, in our symfony2 application, the doctrine-orm (v2.4.7). So this query is auto-generated.

The reason for this error is a wrong syntax of the insert statement:

INSERT INTO state (name, type, group) VALUES ('a_name', 'a_type', 'a_group');

The group column is a sqlite-keyword and must surround with " or '. A query like this

INSERT INTO state (name, type, 'group') VALUES ('a_name', 'a_type', 'a_group');

works fine.



 Comments   
Comment by Florian Semm [ 12/Jan/15 ]

I found the resolution in the documentation





[DBAL-1111] [GH-771] Fix unique index exception handling for an index on multiple columns in PHP 5.4 Created: 11/Jan/15  Updated: 11/Jan/15  Resolved: 11/Jan/15

Status: Resolved
Project: Doctrine DBAL
Component/s: Drivers
Affects Version/s: 2.5
Fix Version/s: 2.6, 2.5.1
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: exceptions, mysql, php-5.4, unique


 Description   

This issue is created automatically through a Github pull request on behalf of rbayliss:

Url: https://github.com/doctrine/dbal/pull/771

Message:

In SQLite under PHP 5.4, when I violate a unique index on multiple columns by creating a duplicate record, the PDO Exception thrown is "SQLSTATE[23000]: Integrity constraint violation: 19 columns X, Y are not unique". This PDO exception message is not parsed by the AbstractSQLiteDriver and converted to a UniqueConstraintViolationException as expected, and as happens in PHP 5.5, so only a generic DriverException is thrown, making error handling much harder.

This pull request adds "are not unique" as a string that is checked for in the exception handling code.



 Comments   
Comment by Doctrine Bot [ 11/Jan/15 ]

A related Github Pull-Request [GH-771] was merged:
https://github.com/doctrine/dbal/pull/771

Comment by Doctrine Bot [ 11/Jan/15 ]

A related Github Pull-Request [GH-771] was assigned:
https://github.com/doctrine/dbal/pull/771





[DBAL-1110] [GH-770] Moved Doctrine\Tests namespace to composer autoload-dev. Created: 11/Jan/15  Updated: 11/Jan/15  Resolved: 11/Jan/15

Status: Closed
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: 2.6
Security Level: All

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: autoloader, composer, phpunit, tests


 Description   

This issue is created automatically through a Github pull request on behalf of guilhermeblanco:

Url: https://github.com/doctrine/dbal/pull/770

Message:



 Comments   
Comment by Doctrine Bot [ 11/Jan/15 ]

A related Github Pull-Request [GH-770] was assigned:
https://github.com/doctrine/dbal/pull/770

Comment by Doctrine Bot [ 11/Jan/15 ]

A related Github Pull-Request [GH-770] was merged:
https://github.com/doctrine/dbal/pull/770





[DBAL-1109] unique-constraints names not quoted on create Created: 11/Jan/15  Updated: 12/Jan/15  Resolved: 12/Jan/15

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: 2.4.3
Fix Version/s: 2.4.4, 2.6, 2.5.1
Security Level: All

Type: Bug Priority: Minor
Reporter: Anders Jenbo Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: create, index, quoted, table
Environment:

Ubuntu 14.04, MySQL 5.5, MySQLi driver

Actual version is 2.4.7 but it doesn’t appear on the list.



 Description   

Having the following line in the xml configurations will cause creation to fail with a sql error because unique is a key word.
<unique-constraint name="unique" columns="unique"/>

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'un
ique (`unique`), PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unic' at line 1






[DBAL-1108] [GH-769] Allow overriding implicit indexes Created: 08/Jan/15  Updated: 14/Jan/15  Resolved: 12/Jan/15

Status: Resolved
Project: Doctrine DBAL
Component/s: Schema Managers
Affects Version/s: 2.5
Fix Version/s: 2.6, 2.5.1
Security Level: All

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: duplicate, explicit, fk, foreign-key, implicit, index, table

Issue Links:
Dependency
is required for DDC-2989 ORM should allow custom index names f... Resolved
Duplicate
is duplicated by DDC-3310 [GH-1138] Join column index names Resolved
Reference
relates to DBAL-1063 Exceptions from SchemaTool when runni... Resolved
relates to DBAL-1102 [GH-764] [DBAL-1063] Allow defining d... Resolved

 Description   

This issue is created automatically through a Github pull request on behalf of deeky666:

Url: https://github.com/doctrine/dbal/pull/769

Message:

This is a follow-up patch for the change introduced in https://github.com/doctrine/dbal/pull/764.
It makes the `Table` class act more intelligent when it comes to preferring explicit over implicit indexes.
Currently it is necessary to construct a `Table` instance in a specific order to not have unnecessary duplicate indexes because of foreign keys. If you first add a foreign key and afterwards and explicit index that is fulfilling the implicit one, both indexes are stored. Instead it is more intelligent to replace the implicit by the explicit one if and only if the explicit one fulfills the implicit one.
This should also fix possible issues with how ORM's schema tool constructs a schema. See [here](https://travis-ci.org/doctrine/doctrine2/jobs/46321581#L307) where for a OneToOne relation on a primary key an additional regular index for the foreign key is created.



 Comments   
Comment by Doctrine Bot [ 09/Jan/15 ]

A related Github Pull-Request [GH-769] was assigned:
https://github.com/doctrine/dbal/pull/769

Comment by Doctrine Bot [ 09/Jan/15 ]

A related Github Pull-Request [GH-769] was merged:
https://github.com/doctrine/dbal/pull/769





[DBAL-1107] Doctrine Migrations diff gets different table name for up and down Created: 06/Jan/15  Updated: 12/Jan/15

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

Type: Bug Priority: Minor
Reporter: Krzysztof Hasiński Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

I've changed one field in my model from not null to default null, generated a migration using diff and got:

class Version20150105175136 extends AbstractMigration
{
    public function up(Schema $schema)
    {
        // this up() migration is auto-generated, please modify it to your needs
        $this->abortIf($this->connection->getDatabasePlatform()->getName() != 'postgresql', 'Migration can only be executed safely on \'postgresql\'.');

        $this->addSql('ALTER TABLE badge ALTER company_id DROP NOT NULL');
    }

    public function down(Schema $schema)
    {
        // this down() migration is auto-generated, please modify it to your needs
        $this->abortIf($this->connection->getDatabasePlatform()->getName() != 'postgresql', 'Migration can only be executed safely on \'postgresql\'.');

        $this->addSql('ALTER TABLE Badge ALTER company_id SET NOT NULL');
    }
}

Please note the name Badge and badge in up and down migrations. Is this a bug?

I've got response from Doctrine Migrations project:

"This should be reported in the issue tracker of the DBAL project, because the Migrations project is not responsible for computing the schema changes."

Link to this issue on github: https://github.com/doctrine/migrations/issues/197



 Comments   
Comment by Steve Müller [ 07/Jan/15 ]

Can you please provide the ORM mapping information before and after the migrations:diff command?
Did you maybe remove or add explicit quotes from/to your table name mapping? Really hard to evaluate without further information...

Comment by Krzysztof Hasiński [ 07/Jan/15 ]

Sure thing:

Entity (imports + header):

use Doctrine\ORM\Mapping as ORM;
use JsonSerializable;
use Iphp\FileStoreBundle\Mapping\Annotation as FileStore;
use Symfony\Component\Validator\Constraints as Assert;
/**
 * Badge
 * @FileStore\Uploadable
 * @ORM\Table()
 * @ORM\Entity
 */
class Badge implements JsonSerializable

Field before change:

    /**
     * @ORM\ManyToOne(targetEntity="Company")
     * @ORM\JoinColumn(nullable=false)
     */
    private $company;

Field after change:

    /**
     * @ORM\ManyToOne(targetEntity="Company")
     * @ORM\JoinColumn(nullable=true)
     */
    private $company;

Comment by Steve Müller [ 09/Jan/15 ]

How is your table named in the database? Is it "Badge" or "badge"? I assume that your table was created with the name "Badge" (with a capital letter). If this is the case, did you have your table name explicitly quoted in the mapping some time before like `Badge` or "Badge" (including backticks/quotes)?

Comment by Krzysztof Hasiński [ 09/Jan/15 ]

Created using migrations:diff, relevant line (note the capital letter):

        $this->addSql("CREATE TABLE Badge (id INT NOT NULL, user_id INT DEFAULT NULL, team_id VARCHAR(63) NOT NULL, name VARCHAR(255) NOT NULL, image VARCHAR(512) NOT NULL, condition TEXT NOT NULL, PRIMARY KEY(id))");

In all subsequent migrations any ALTER TABLE (generated) is using this mixed case for up and down.

Status in db now (from psql):

khasinski=> \d badge
                          Table "public.badge"
   Column    |          Type           |            Modifiers            
-------------+-------------------------+---------------------------------
 id          | integer                 | not null
 user_id     | integer                 | 
 company_id  | character varying(63)   | not null
 name        | character varying(255)  | not null
 image       | text                    | not null
 condition   | text                    | 
 description | character varying(1024) | default NULL::character varying
Indexes:
    "badge_pkey" PRIMARY KEY, btree (id)
    "idx_3f316719296cd8ae" btree (company_id)
    "idx_3f316719a76ed395" btree (user_id)
Foreign-key constraints:
    "fk_3f316719296cd8ae" FOREIGN KEY (company_id) REFERENCES company(id)
    "fk_3f316719a76ed395" FOREIGN KEY (user_id) REFERENCES guser(id)
Referenced by:
    TABLE "userbadge" CONSTRAINT "fk_9a64d968f7a2c2fc" FOREIGN KEY (badge_id) REFERENCES badge(id)
Comment by Marco Pivetta [ 09/Jan/15 ]

Can you please tell us the exact versions (see composer.lock) of the DBAL, ORM and migrations installed?

Comment by Krzysztof Hasiński [ 09/Jan/15 ]

Sure, always happy to help

DBAL:

            "name": "doctrine/dbal",
            "version": "v2.5.0",
            "source": {
                "type": "git",
                "url": "https://github.com/doctrine/dbal.git",
                "reference": "71140662c0a954602e81271667b6e03d9f53ea34"
            },
            "dist": {
                "type": "zip",
                "url": "https://api.github.com/repos/doctrine/dbal/zipball/71140662c0a954602e81271667b6e03d9f53ea34",
                "reference": "71140662c0a954602e81271667b6e03d9f53ea34",
                "shasum": ""
            },

ORM:

            "name": "doctrine/orm",
            "version": "v2.4.7",
            "source": {
                "type": "git",
                "url": "https://github.com/doctrine/doctrine2.git",
                "reference": "2bc4ff3cab2ae297bcd05f2e619d42e6a7ca9e68"
            },
            "dist": {
                "type": "zip",
                "url": "https://api.github.com/repos/doctrine/doctrine2/zipball/2bc4ff3cab2ae297bcd05f2e619d42e6a7ca9e68",
                "reference": "2bc4ff3cab2ae297bcd05f2e619d42e6a7ca9e68",
                "shasum": ""
            },

Migrations:

            "name": "doctrine/doctrine-migrations-bundle",
            "version": "dev-master",
            "target-dir": "Doctrine/Bundle/MigrationsBundle",
            "source": {
                "type": "git",
                "url": "https://github.com/doctrine/DoctrineMigrationsBundle.git",
                "reference": "81575a4316951125ce408c70f30547c77d98f78a"
            },
            "dist": {
                "type": "zip",
                "url": "https://api.github.com/repos/doctrine/DoctrineMigrationsBundle/zipball/81575a4316951125ce408c70f30547c77d98f78a",
                "reference": "81575a4316951125ce408c70f30547c77d98f78a",
                "shasum": ""
            },
Comment by Steve Müller [ 09/Jan/15 ]

I think I get the problem here. Btw do the migrations actually fail? IMO this is not really an "issue" as casing of identifiers is ignored by PostgreSQL unless you explicitly quote identifiers. So:

ALTER TABLE badge ALTER company_id DROP NOT NULL;
ALTER TABLE Badge ALTER company_id DROP NOT NULL;
ALTER TABLE BADGE ALTER company_id DROP NOT NULL;

all do the same thing because PostgreSQL internally lowercases identifiers if they are not quoted.
Please see: http://www.alberton.info/dbms_identifiers_and_case_sensitivity.html#.VLAQal0z1C0

Comment by Steve Müller [ 09/Jan/15 ]

BTW if you find it annoying that migrations uses "Badge" instead of "badge" you'll just have to use another naming strategy.
See: http://doctrine-orm.readthedocs.org/en/latest/reference/namingstrategy.html

Comment by Krzysztof Hasiński [ 09/Jan/15 ]

I am well aware, that PostgreSQL use lowercase when it comes to table names without a quote, that's why I'm not considering a major bug, just some inconsistency, that I was curious about. It seems like up and down migrations should read the data from a single source of truth.

I might be mistaken, but it seems like migrations are important enough to care about this kind of minor details.

Comment by Steve Müller [ 12/Jan/15 ]

The DBAL schema manager that introspects your database does not know about your schema mappings you defned in ORM so it won't know that you created the table with an uppercase first letter. If you want consistency, please use another naming strategy in ORM or quote your table identifier explicitly in your mapping.
Doctrine will only quote reserved keyword identifiers and does not quote all identifiers automatically. There have been several discussions about this to why auto-quoting brings more problems than it solves.

Comment by Krzysztof Hasiński [ 12/Jan/15 ]

As I said - I am aware of that and it's probably ok

So my understanding is that it creates "up" migrations from ORM (which knows about the capital letter) and "down" using DBAL schema manager, is that correct?

Comment by Steve Müller [ 12/Jan/15 ]

I think you mean the other way around. See here: https://github.com/doctrine/migrations/blob/master/lib/Doctrine/DBAL/Migrations/Tools/Console/Command/DiffCommand.php#L101-L102
For "up" migrations the ORM schema mapping is compared against the database schema mapping (base). For "down" migrations it's the other way around.





[DBAL-1106] [GH-768] [DBAL-1106] Improve schema introspection performance on Oracle Created: 04/Jan/15  Updated: 04/Jan/15  Resolved: 04/Jan/15

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms, Schema Managers
Affects Version/s: 2.5
Fix Version/s: 2.6
Security Level: All

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: ddl, introspection, oracle, performance, schema


 Description   

This issue is created automatically through a Github pull request on behalf of deeky666:

Url: https://github.com/doctrine/dbal/pull/768

Message:

This PR improves the overall schema introspection performance on Oracle by optimizing some of the `getList*()` method SQL queries in the platform.
Unfortunately Oracle system views are rather slow, especially when joining tables. Using subqueries can improve the execution time a lot.

*Improved queries*

(the times have been measured using an exemplary query from the functional test suite)

`getListTableForeignKeysSQL()`: Down from `~2.33s` to `~0.68s` per query
`getListTableColumnsSQL()`: Down from `~0.49s` to `~0.14s` per query
`getListTableIndexesSQL()`: Down from `~0.5s` to `~0.25s` per query

Overall improvement of `OracleSchemaManagerTest` from `~100s` to `~37.5s`.

I was quite impressed by the performance improvements



 Comments   
Comment by Doctrine Bot [ 04/Jan/15 ]

A related Github Pull-Request [GH-768] was assigned:
https://github.com/doctrine/dbal/pull/768

Comment by Doctrine Bot [ 04/Jan/15 ]

A related Github Pull-Request [GH-768] was merged:
https://github.com/doctrine/dbal/pull/768





[DBAL-1105] [GH-767] Removed drizzle support. Created: 04/Jan/15  Updated: 04/Jan/15

Status: Open
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of kimhemsoe:

Url: https://github.com/doctrine/dbal/pull/767

Message:






[DBAL-1104] [GH-766] [DBAL-1104] Add support for object hydration in oci8 driver Created: 04/Jan/15  Updated: 04/Jan/15  Resolved: 04/Jan/15

Status: Resolved
Project: Doctrine DBAL
Component/s: Drivers
Affects Version/s: None
Fix Version/s: 2.6
Security Level: All

Type: New Feature Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: driver, fetch, object, oci8, oracle


 Description   

This issue is created automatically through a Github pull request on behalf of deeky666:

Url: https://github.com/doctrine/dbal/pull/766

Message:

Adds support for fetching data into `\stdClass` objects in `oci8` driver.



 Comments   
Comment by Doctrine Bot [ 04/Jan/15 ]

A related Github Pull-Request [GH-766] was assigned:
https://github.com/doctrine/dbal/pull/766

Comment by Doctrine Bot [ 04/Jan/15 ]

A related Github Pull-Request [GH-766] was merged:
https://github.com/doctrine/dbal/pull/766





[DBAL-1103] [GH-765] Remove PHP 5.3 support Created: 03/Jan/15  Updated: 03/Jan/15

Status: Open
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of Ocramius:

Url: https://github.com/doctrine/dbal/pull/765

Message:

Just a suggestion for master (2.6). We should move on.



 Comments   
Comment by Doctrine Bot [ 03/Jan/15 ]

A related Github Pull-Request [GH-765] was assigned:
https://github.com/doctrine/dbal/pull/765





[DBAL-1102] [GH-764] [DBAL-1063] Allow defining duplicate indexes on a table Created: 03/Jan/15  Updated: 08/Jan/15  Resolved: 03/Jan/15

Status: Resolved
Project: Doctrine DBAL
Component/s: Schema Managers
Affects Version/s: 2.5
Fix Version/s: 2.6, 2.5.1
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: ddl, index, rename, schema

Issue Links:
Reference
relates to DBAL-1063 Exceptions from SchemaTool when runni... Resolved
is referenced by DBAL-1108 [GH-769] Allow overriding implicit in... Resolved

 Description   

This issue is created automatically through a Github pull request on behalf of deeky666:

Url: https://github.com/doctrine/dbal/pull/764

Message:

This PR removes silent dropping of "duplicate" indexes on a table if two indexes fulfill each other or one overrules the other.
This is necessary to make detection of renamed indexes work properly (introduced in 2.5). Currently there are situations where false positive index renamings are detected because of race conditions.

*Example*

An ORM entity contains an association which adds a foreign key constraint to the underlying table. Foreign key constraints always create implicit indexes on the particular columns.
The entity also contains a mapping for a custom named index fulfilling the foreign key column(s).
The ORM schema tool first adds the foreign key constraint to the table, implicitly creating an index. Afterwards it adds the custom named index which is dropped silently by the table instance because it is considered a "duplicate".
So the table instance created by the schema now contains the auto generated index but not the custom named one.
When using the schema tool to update the schema, the DBAL schema manager is utilized to create the "online" schema. The schema manager detects two indexes in the database, the auto generated one and the custom named one (manually created by the user).
When the schema manger creates the table instance it eventually adds the custom named index first which results in the auto generated index being dropped silently.
When comparing both "offline" and "online" schema, the comparator detects an index rename which actually is none.
This leads to failing `DROP INDEX` and `CREATE INDEX` SQL.

Besides this issue "duplicate" indexes are totally legit and DBAL should not decide whether or not to create an index. This should be user responsibility.

This implementation is much more transparent and less error prone and opens up more flexibility for the user to define indexes on tables.

/cc @flack @Ocramius @beberlei



 Comments   
Comment by Doctrine Bot [ 03/Jan/15 ]

A related Github Pull-Request [GH-743] was closed:
https://github.com/doctrine/dbal/pull/743

Comment by Doctrine Bot [ 03/Jan/15 ]

A related Github Pull-Request [GH-743] was assigned:
https://github.com/doctrine/dbal/pull/743

Comment by Doctrine Bot [ 03/Jan/15 ]

A related Github Pull-Request [GH-764] was assigned:
https://github.com/doctrine/dbal/pull/764

Comment by Doctrine Bot [ 03/Jan/15 ]

A related Github Pull-Request [GH-764] was merged:
https://github.com/doctrine/dbal/pull/764





[DBAL-1101] [GH-763] Add date formatting and from/to unix timestamp conversion Created: 03/Jan/15  Updated: 05/Jan/15  Resolved: 05/Jan/15

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: New Feature Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Incomplete Votes: 0
Labels: conversion, date, format, sql, timestamp, unix


 Description   

This issue is created automatically through a Github pull request on behalf of andig:

Url: https://github.com/doctrine/dbal/pull/763

Message:

I'm proposing to add date formatting as well as from/to unix timestamp conversion to DBAL. If this PR is going to find resonance I'd gladly add implementations for SQlite and MySQL.

Please let me know if this is something worth to pursue.



 Comments   
Comment by Doctrine Bot [ 05/Jan/15 ]

A related Github Pull-Request [GH-763] was closed:
https://github.com/doctrine/dbal/pull/763





[DBAL-1100] [GH-762] PostgreSQL needs explicitly closed connection in functional test Created: 03/Jan/15  Updated: 03/Jan/15  Resolved: 03/Jan/15

Status: Resolved
Project: Doctrine DBAL
Component/s: Drivers
Affects Version/s: 2.5, 2.4.3
Fix Version/s: 2.6, 2.5.1
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: connection, postgresql, process-isolation, tests


 Description   

This issue is created automatically through a Github pull request on behalf of sarcher:

Url: https://github.com/doctrine/dbal/pull/762

Message:

The test `Doctrine\Tests\DBAL\Functional\ConnectionTest::testConnectWithoutExplicitDatabaseName` prevents further tests in the suite from being run as the connection hangs around in PostgreSQL.

After this particular test, when the next `DROP DATABASE` is run, the log shows:

> 2015-01-03 00:21:28 PST ERROR: database "doctrine_tests" is being accessed by other users
> 2015-01-03 00:21:28 PST DETAIL: There is 1 other session using the database.
> 2015-01-03 00:21:28 PST STATEMENT: DROP DATABASE doctrine_tests

And the next functional test to be run produces something like:

> 1) Doctrine\Tests\DBAL\Functional\ConnectionTest::testPingDoesTriggersConnect
> Doctrine\DBAL\Exception\DriverException: An exception occurred while executing 'CREATE DATABASE doctrine_tests':
>
> SQLSTATE[42P04]: Duplicate database: 7 ERROR: database "doctrine_tests" already exists
>
> ...

This is with the following:

  • Debian Linux
  • PHP 5.5.9
  • PostgreSQL 9.3.5
  • PHPUnit 4.0.20
  • Process Isolation = off

Turning process isolation on does resolve the issue, but I assume that shouldn't be required. This doesn't seem to affect Travis.



 Comments   
Comment by Doctrine Bot [ 03/Jan/15 ]

A related Github Pull-Request [GH-762] was assigned:
https://github.com/doctrine/dbal/pull/762

Comment by Doctrine Bot [ 03/Jan/15 ]

A related Github Pull-Request [GH-762] was merged:
https://github.com/doctrine/dbal/pull/762





[DBAL-1099] Unittests for Drizzle Platform Created: 02/Jan/15  Updated: 07/Jan/15  Resolved: 07/Jan/15

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Improvement Priority: Minor
Reporter: Claudio Assignee: Benjamin Eberlei
Resolution: Won't Fix Votes: 0
Labels: Drizzle, dbal


 Description   

I've realized that the DrizzlePlatform has no unittests at the moment and it should get some. Usually unittests are a must have and every new code should get their tests. DrizzlePlatform is not a new contribution so I'm wodering why it lacks unittests.

What are the reasons that DrizzlePlatform has no unittests?



 Comments   
Comment by Marco Pivetta [ 02/Jan/15 ]

What are the reasons that DrizzlePlatform has no unittests?

It probably just got in when we weren't strict about tests (nor had CI integration yet)

Comment by Claudio [ 02/Jan/15 ]

Sounds to me like unittests are welcome.

Comment by Benjamin Eberlei [ 02/Jan/15 ]

We should rather be removing Drizzle support in an upcoming version (DBAL 2.6), as the database is not developed anymore.

Comment by Marco Pivetta [ 02/Jan/15 ]

Tests are always very welcome.

Comment by Claudio [ 02/Jan/15 ]

Benjamin Eberlei You're more into never touch DrizzlePlatform again? I didn't know that Drizzle isn't developed anymore and I'm not sure if anyone is even using Drizzle with Doctrine DBAL.

Comment by Claudio [ 07/Jan/15 ]

Since Benjamin Eberlei suggested to remove Drizzle and a PR already exists for that (DBAL-1105) (https://github.com/doctrine/dbal/pull/767), I close this issue.





[DBAL-1098] [GH-761] Fixed typo Created: 02/Jan/15  Updated: 02/Jan/15  Resolved: 02/Jan/15

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: 2.6
Security Level: All

Type: Documentation Priority: Trivial
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: typo


 Description   

This issue is created automatically through a Github pull request on behalf of BenMorel:

Url: https://github.com/doctrine/dbal/pull/761

Message:



 Comments   
Comment by Doctrine Bot [ 02/Jan/15 ]

A related Github Pull-Request [GH-761] was closed:
https://github.com/doctrine/dbal/pull/761





[DBAL-1097] [GH-760] [DBAL-1097] Fix foreign key constraint referential action on Oracle Created: 31/Dec/14  Updated: 01/Jan/15  Resolved: 01/Jan/15

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: None
Fix Version/s: 2.4.4, 2.6, 2.5.1
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: action, constraint, fk, foreignkey, noaction, ondelete, oracle, referential, restrict


 Description   

This issue is created automatically through a Github pull request on behalf of deeky666:

Url: https://github.com/doctrine/dbal/pull/760

Message:

Oracle only supports `CASCADE` and `SET NULL` referential actions for foreign key constraints. It also supports `NO ACTION` but it cannot be declared with an explicit `ON DELETE NO ACTION` clause. The complete clause has to be omitted in order to make it work.
This PR fixes supported referential actions and omits the referential clause if either action `NO ACTION` or `RESTRICT` is set for the foreign key constraint to create.



 Comments   
Comment by Doctrine Bot [ 31/Dec/14 ]

A related Github Pull-Request [GH-760] was assigned:
https://github.com/doctrine/dbal/pull/760

Comment by Doctrine Bot [ 01/Jan/15 ]

A related Github Pull-Request [GH-760] was closed:
https://github.com/doctrine/dbal/pull/760





[DBAL-1096] schema-tool:update does not understand columnDefinition correctly Created: 30/Dec/14  Updated: 08/Jan/15  Resolved: 31/Dec/14

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

Type: Improvement Priority: Major
Reporter: Benjamin Morel Assignee: Marco Pivetta
Resolution: Can't Fix Votes: 0
Labels: None

Issue Links:
Duplicate
duplicates DBAL-167 Schema comparator doesn't work proper... Open
Reference
relates to DDC-1657 The Doctrine cli tool does not handl... Resolved
relates to DDC-625 orm:schema-tool:update --dump-sql sho... Resolved

 Description   

This issue is similar to the old DDC-625 and to DDC-1657, but its scope is limited to columns declared with columnDefinition.

Take this entity:

class Faq
{
    /**
     * @ORM\Column(type="integer", columnDefinition="TINYINT(3) UNSIGNED NOT NULL")
     *
     * @var integer
     */
    private $position;
}

The command doctrine orm:schema-tool:update --dump-sql generates the following output:

ALTER TABLE Faq CHANGE position position TINYINT(3) UNSIGNED NOT NULL;

Even though the column is already declared this way. If I manually execute this query, and run the tool again, I get the same output.

I'm using Doctrine 2.4.7 with PHP 5.5.12 and MySQL 5.6.17.



 Comments   
Comment by Marco Pivetta [ 31/Dec/14 ]

The schema tool can't and won't handle diffs containing custom columnDefinition.

Comment by Benjamin Morel [ 31/Dec/14 ]

@ocramius Can you tell me why? Can't it at the very least compare them as strings, to avoid repeating endlessly the same queries?

Comment by Marco Pivetta [ 31/Dec/14 ]

That's exactly the problem: string comparison won't work in these cases, because of minor mismatches and because the column definition may include special markers, comments, definitions and so on in scrambled order.

This limitation is also documented in http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/annotations-reference.html#column

Handling it goes beyond the scope of the schema comparator, as the complexity to deal with it is not worth the effort.

Comment by Benjamin Morel [ 31/Dec/14 ]

While I fully understand these concerns, it's really disappointing to have to either stick to default, unoptimized data types such as INT when you only need a 8- or 16-bit integer, or to have to give up the command-line schema validation tool that will always go red.

The same issue applies when using custom data types such as Geometry or LocalDate, even when using supported SQL declarations.
This restricts a lot what you can do with the ORM while keeping the convenience of the schema tools!

I may have a few ideas to try out to make this work; if the core team is not 100% opposed to the concept, I could open a PR with a proof of concept at some point.

Comment by Marco Pivetta [ 31/Dec/14 ]

Fine tuning is the job of a DBA, not of the schema-tool. The schema-tool is by far a silver bullet.

Comment by Steve Müller [ 31/Dec/14 ]

Benjamin Morel if you find a way to make custom columnDefinitions comparable in a reasonable way, go ahead, make a contribution. It's not that we are totally against it, we just didn't find a good solution so far to make it work in a usable way. By the way, this is actually a DBAL issue, moving.

Comment by Christophe Coevoet [ 31/Dec/14 ]

Note that for custom data types, the SchemaTool supports comparing them if you use custom DBAL types to map them instead of using an existing type and adding a customDefinition property in it (the result might even be a better integration)

Comment by Benjamin Morel [ 31/Dec/14 ]

@Christophe Hmm I'm going to play a bit with this, but the LocalDate custom type I mentioned above, even though it uses $platform->getDateTypeDeclarationSQL(), is not properly handled by the SchemaTool either (it also endlessly suggests the same DDL)!

Comment by Steve Müller [ 31/Dec/14 ]

Benjamin Morel try making your custom type a commented type. This should make the schema manager be able to distinguish your custom type from the default DateType.
Override the method requiresSQLCommentHint() in your custom type class and let it return true.

Comment by Benjamin Morel [ 05/Jan/15 ]

Steve Müller It works indeed with requiresSQLCommentHint(), I didn't know about that, thank you.

As far as I can see, the commented types are not checked by the SchemaTool: if I manually change a commented column type in the database, schema-tool:update won't offer me to fix it.

Could we do the same thing for columns with a columnDefinition? i.e. comment them with DC2Type:integer or DC2Type:string or whatever the native type is, and have the SchemaTool skip them?

Comment by Steve Müller [ 05/Jan/15 ]

Benjamin Morel actually it is the DBAL schema manager that is extracting the custom type name from the column's comment and then mapping it accordingly.
For instance if your custom type is called "money" (which is based on the native "decimal" type for example), DBAL will add the string "(DC2Type:money)" to the column's comment on creation/update. On reverse engineering the column from the database the schema manager will first detect the column as "decimal" (native type), then check for the custom type string in the comment and convert it into the "money" type.
This should work out of the box but is processed by DBAL, not ORM's schema tool. The schema tool just utilizes DBAL's schema manager here.
Speaking of custom columnDefinition your idea sounds reasonable to me and I think to remember that something similar has been proposed in the past. However to make matching and extraction easier we should hash the columnDefinition string somehow.

Comment by Benjamin Morel [ 05/Jan/15 ]

Steve Müller Including a hash of the column definition in the DC2Type comment is a good idea, however it would only detect when you update the definition in the entity, not when you update the column type in the database manually.

I would be happy to work on this suggestion anyway, but I'm not sure where to start as I'm not comfortable with the internals of the schema manager.

Comment by Steve Müller [ 05/Jan/15 ]

Benjamin Morel of course we would have to make a compromise here. Comparing the column declaration SQL coming from the database with an arbitrary column declaration string from the mapping is not safe and also impossible considering that you usually use the columnDefinition to define vendor specific semantics for the column that DBAL does not/cannot support.
Implementing this feature would be similar to the commented type one.

Places to start:

https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Schema/AbstractSchemaManager.php#L1085-L1112
https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Schema/MySqlSchemaManager.php#L129-L132 (needs to be adopted for all schema managers)
https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Platforms/AbstractPlatform.php#L497-L525

Those should be the important parts to adopt. Feel free to provide a PR

Comment by Steve Müller [ 08/Jan/15 ]

Related: DBAL-167





[DBAL-1095] [GH-759] [DBAL-1095] Fix index introspection on SQL Anywhere Created: 28/Dec/14  Updated: 28/Dec/14  Resolved: 28/Dec/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms, Schema Managers
Affects Version/s: 2.5
Fix Version/s: 2.6, 2.5.1
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: foreignkey, index, sqlanywhere


 Description   

This issue is created automatically through a Github pull request on behalf of deeky666:

Url: https://github.com/doctrine/dbal/pull/759

Message:

SQL Anywhere creates indexes implicitly for foreign key constraints. Thoses should not be introspected by the schema manager to avoid unnecessary schema updates with ORM's schema tool. DBAL already creates indexes for foreign key constraints implicitly...



 Comments   
Comment by Doctrine Bot [ 28/Dec/14 ]

A related Github Pull-Request [GH-759] was assigned:
https://github.com/doctrine/dbal/pull/759

Comment by Doctrine Bot [ 28/Dec/14 ]

A related Github Pull-Request [GH-759] was closed:
https://github.com/doctrine/dbal/pull/759





[DBAL-1094] [GH-758] Cleanup travis database creation Created: 26/Dec/14  Updated: 27/Dec/14  Resolved: 27/Dec/14

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: 2.6
Security Level: All

Type: Improvement Priority: Trivial
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: travis


 Description   

This issue is created automatically through a Github pull request on behalf of deeky666:

Url: https://github.com/doctrine/dbal/pull/758

Message:

Remove database creation from Travis build script because it is actually done by DBAL test suite already. Moreover it avoids creating temp databases which are useless and not even used by PostgreSQL currently.



 Comments   
Comment by Doctrine Bot [ 26/Dec/14 ]

A related Github Pull-Request [GH-758] was assigned:
https://github.com/doctrine/dbal/pull/758

Comment by Doctrine Bot [ 27/Dec/14 ]

A related Github Pull-Request [GH-758] was closed:
https://github.com/doctrine/dbal/pull/758





[DBAL-1093] [GH-757] Fix creating and dropping database on PostgreSQL Created: 26/Dec/14  Updated: 13/Jan/15  Resolved: 27/Dec/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Schema Managers
Affects Version/s: None
Fix Version/s: 2.4.4, 2.6, 2.5.1
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: create, database, drop, pgsql, postgresql

Issue Links:
Reference
is referenced by DBAL-1114 Problem with drop database on PostgreSQL Open

 Description   

This issue is created automatically through a Github pull request on behalf of deeky666:

Url: https://github.com/doctrine/dbal/pull/757

Message:

There is some useless code in the schema manager for PostgreSQL for creating and dropping a database. Moreover if either of those operations fails, the schema manager stays in an inconsistent state because the temporary connection that is set in the schema manager is not reverted back to the original connection.



 Comments   
Comment by Doctrine Bot [ 26/Dec/14 ]

A related Github Pull-Request [GH-757] was assigned:
https://github.com/doctrine/dbal/pull/757

Comment by Doctrine Bot [ 27/Dec/14 ]

A related Github Pull-Request [GH-757] was closed:
https://github.com/doctrine/dbal/pull/757





[DBAL-1092] [GH-756] [DBAL-1062] Fix renaming indexes used by foreign key constraints Created: 24/Dec/14  Updated: 26/Dec/14  Resolved: 26/Dec/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: 2.5
Fix Version/s: 2.6, 2.5.1
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: index, rename

Issue Links:
Reference
relates to DBAL-1062 upgrade from v2.4.3 to v2.5.0 is forc... Resolved

 Description   

This issue is created automatically through a Github pull request on behalf of deeky666:

Url: https://github.com/doctrine/dbal/pull/756

Message:

Platforms that do not support a SQL syntax for natively renaming indexes need to drop and recreate indexes to perform a rename.
Platforms like MySQL < 5.7 deny dropping indexes used by foreign key constraints. In this case foreign key constraints have to be dropped before dropping indexes and have to be recreated after the particular index(es) have been recreated.
This is a major issue right now for people trying to upgrade to DBAL 2.5.



 Comments   
Comment by Doctrine Bot [ 24/Dec/14 ]

A related Github Pull-Request [GH-756] was assigned:
https://github.com/doctrine/dbal/pull/756

Comment by Doctrine Bot [ 26/Dec/14 ]

A related Github Pull-Request [GH-756] was closed:
https://github.com/doctrine/dbal/pull/756





[DBAL-1091] [GH-755] Update MysqliStatement to support PDO::FETCH_OBJ Created: 23/Dec/14  Updated: 04/Jan/15  Resolved: 04/Jan/15

Status: Resolved
Project: Doctrine DBAL
Component/s: Drivers
Affects Version/s: None
Fix Version/s: 2.6
Security Level: All

Type: New Feature Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: driver, fetch, mysql, mysqli, object


 Description   

This issue is created automatically through a Github pull request on behalf of gohanman:

Url: https://github.com/doctrine/dbal/pull/755

Message:

Return a simple stdClass object if that fetch type is requested.



 Comments   
Comment by Doctrine Bot [ 04/Jan/15 ]

A related Github Pull-Request [GH-755] was merged:
https://github.com/doctrine/dbal/pull/755





[DBAL-1090] [GH-754] Changing string to fixed string is not recognized in PostgreSQL Platform Created: 21/Dec/14  Updated: 26/Dec/14  Resolved: 26/Dec/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: None
Fix Version/s: 2.4.4, 2.6, 2.5.1
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: dbal, postgresql


 Description   

This issue is created automatically through a Github pull request on behalf of SenseException:

Url: https://github.com/doctrine/dbal/pull/754

Message:

The following change of an entity using PostgreSQL is not recognized by Doctrine DBAL:
from

    /**
     * @ORM\Column(type="string", name="name", length=2)
     */
    public $name;

to

    /**
     * @ORM\Column(type="string", name="name", length=2, options={"fixed"=true})
     */
    public $name;

A schema-update should change the column from `character varying(2)` to `character(2)` but instead acts like no changes were made on the column.

With this PR, I've extended the `PostgreSqlPlatform` to detect changes of the fixed option of a column.



 Comments   
Comment by Doctrine Bot [ 26/Dec/14 ]

A related Github Pull-Request [GH-754] was closed:
https://github.com/doctrine/dbal/pull/754





[DBAL-1089] [GH-753] Add a unit test for broken backslashes on MySQL in LIKE Created: 19/Dec/14  Updated: 19/Dec/14

Status: Open
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of nickvergessen:

Url: https://github.com/doctrine/dbal/pull/753

Message:






[DBAL-1088] [GH-752] Fix error handling restore Created: 19/Dec/14  Updated: 31/Dec/14  Resolved: 31/Dec/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Drivers
Affects Version/s: None
Fix Version/s: 2.6, 2.5.1
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: connection, error, handler, mysqli


 Description   

This issue is created automatically through a Github pull request on behalf of nicolas-grekas:

Url: https://github.com/doctrine/dbal/pull/752

Message:

PHP already handles an internal stack of error handlers



 Comments   
Comment by Doctrine Bot [ 24/Dec/14 ]

A related Github Pull-Request [GH-752] was assigned:
https://github.com/doctrine/dbal/pull/752

Comment by Doctrine Bot [ 31/Dec/14 ]

A related Github Pull-Request [GH-752] was closed:
https://github.com/doctrine/dbal/pull/752





[DBAL-1087] [GH-751] Length of fixed string type (char) is ignored on Postgre schema update Created: 19/Dec/14  Updated: 31/Dec/14  Resolved: 31/Dec/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Schema Managers
Affects Version/s: None
Fix Version/s: 2.4.4, 2.6, 2.5.1
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: dbal, postgresql, schemamanager


 Description   

This issue is created automatically through a Github pull request on behalf of SenseException:

Url: https://github.com/doctrine/dbal/pull/751

Message:

This PR should fix an issue for the fixed string type columns using PostgreSQL.

I've created a basic Symfony 2.6. Application and using a PostgreSQL 9.3. database. In this dummy project, I've created the following Entity:

<?php

namespace Acme\DemoBundle\Entity;

use Doctrine\ORM\Mapping AS ORM;

/**
 * @ORM\Entity
 * @ORM\Table(name="test")
 */
class Test
{
    /**
     * @ORM\Id
     * @ORM\Column(type="integer", name="id")
     * @ORM\GeneratedValue
     */
    public $id;

    /**
     * @ORM\Column(type="string", name="name", length=2, options={"fixed" = true})
     */
    public $name;
}

The table is successfully created after a schema update, but when another schema update is executed without any changes to the entity, an ALTER query is executed:

ALTER TABLE test ALTER name TYPE CHAR(2);

After I searched in the code of doctrine dbal, I discovered that the length of the char column is not fetched correctly in `PostgreSqlSchemaManager::_getPortableTableColumnDefinition()`. In my example, length results as `null` and will be later set to 255 in the `Comparator`, which isn't the correct length from the database column. The comparation of the schemas results in a change of char-length.

For simplicity, I extended the if-condition in `PostgreSqlSchemaManager` to:

if (strtolower($tableColumn['type']) === 'varchar' || strtolower($tableColumn['type']) === 'bpchar') {

The fix I've contributed does help to parse the length in my case, but when I look into `PostgreSqlPlatform::initializeDoctrineTypeMappings()` there could be other types with the same problem, that are mapped to the doctrine string type.

// ... part of PostgreSqlPlatform::initializeDoctrineTypeMappings()
            'varchar'       => 'string',
            'interval'      => 'string',
            '_varchar'      => 'string',
            'char'          => 'string',
            'bpchar'        => 'string',
            'inet'          => 'string',

I guess we need to cover `char` and the others too.

`PostgreSqlSchemaManagerTest` also doesn't cover existing code. How is this going to be tested? Does the SchemaManagers need some tests in general?



 Comments   
Comment by Doctrine Bot [ 31/Dec/14 ]

A related Github Pull-Request [GH-751] was closed:
https://github.com/doctrine/dbal/pull/751





[DBAL-1086] [GH-750] Store the parameters of the chosen connection when using Master/Slave. Created: 19/Dec/14  Updated: 04/Jan/15

Status: Open
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of xrash:

Url: https://github.com/doctrine/dbal/pull/750

Message:

When using the MasterSlaveConnection, the internal parameters array has a different structure than the usual Connection. This can cause the following methods to fail: getHost(), getPort(), getUsername() and getPassword().

I changed the MasterSlaveConnection so that it stores the parameters of the chosen connection in a private property. With this change, the methods that used to fail can now retrieve the configuration for the actual chosen connection, which is, in my opinion, clearly the expected behavior.

I chose to create a new private property in MasterSlaveConnection instead of inherit the $_params from Connection in order to not cause any confusion by having two different array structures in the same variable at different situations.

I also expanded the tests for this case.



 Comments   
Comment by Doctrine Bot [ 04/Jan/15 ]

A related Github Pull-Request [GH-750] was assigned:
https://github.com/doctrine/dbal/pull/750





[DBAL-1085] Custom Type Compare Fails To Generate Correct Migrations Created: 19/Dec/14  Updated: 24/Dec/14  Resolved: 24/Dec/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Schema Managers
Affects Version/s: 2.0, 2.1, 2.2, 2.3, 2.4
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Nicolas Vanheuverzwijn Assignee: Steve Müller
Resolution: Invalid Votes: 0
Labels: migrations
Environment:

Everywhere



 Description   

// From doctrine 2.1
public function diffColumn(Column $column1, Column $column2)
{
$changedProperties = array();
if ( $column1->getType() != $column2->getType() )

{ $changedProperties[] = 'type'; }

...
}
The $column1->getType() will return the underlying platform object but the $column2->getType() will return the custom object type.

Because of the way the php compare function works, a custom type will always generate a changed property over the type of a column.

http://stackoverflow.com/questions/26964367/symfony2-doctrine-custom-types-generating-unneeded-migrations/27557785#27557785



 Comments   
Comment by Steve Müller [ 24/Dec/14 ]

Nicolas Vanheuverzwijn I think you will have to mark your custom type as requiring a SQL comment, otherwise the schema manager cannot distinguish between DateTime type and your custom type because both map to the same native SQL type. See here:

https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Types/Type.php#L327-L340

You will have to add the following to your custom type implementation:

/**
 * {@inheritdoc}
 */
public function requiresSQLCommentHint(AbstractPlatform $platform)
{
    return true;
}

Also I think it might be required to give your custom type a distinct name like:

/**
 * {@inheritdoc}
 */
public function getName()
{
    return 'datetime_utc';
}
Comment by Steve Müller [ 24/Dec/14 ]

See also: http://doctrine-orm.readthedocs.org/en/latest/cookbook/custom-mapping-types.html

Comment by Nicolas Vanheuverzwijn [ 24/Dec/14 ]

Wow, I shall take a look at this. This might be it ! Thanks a lot for your reply.

Comment by Steve Müller [ 24/Dec/14 ]

You're welcome. Can you please report if that fixed your problem so we can closse the issue eventually? Thanks.

Comment by Nicolas Vanheuverzwijn [ 24/Dec/14 ]

Yes sir. The problem I have was that I am using doctrine 2.2. I shall migrate my stuff to doctrine 2.5 and use that feature.

Comment by Nicolas Vanheuverzwijn [ 24/Dec/14 ]

This feature is implemented in version >=2.3 of Doctrine/DBAL.

Comment by Steve Müller [ 24/Dec/14 ]

Yes. 2.2 is EOL anyways and I think 2.3 is now only getting security fixes so an upgrade to at least 2.4 is highly recommended.





[DBAL-1084] MySQL DateTime fractional seconds exception Created: 18/Dec/14  Updated: 31/Dec/14

Status: Open
Project: Doctrine DBAL
Component/s: None
Affects Version/s: 2.4.2
Fix Version/s: None
Security Level: All

Type: New Feature Priority: Major
Reporter: Jachim Coudenys Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

MySQL 5.6.4+



 Description   

Since MySQL 5.6.4 it is possible to include fractional seconds in datetime/timestamp fields.

Doctrine cannot handle this at the moment, and it is not clear how this can be resolved.

Doctrine\DBAL\Types\ConversionException(#67): Could not convert database value "2014-12-16 17:06:38.385" to Doctrine Type datetime. Expected format: Y-m-d H:i:s
  #0 /var/www/vendor/doctrine/dbal/lib/Doctrine/DBAL/Types/DateTimeType.php(67): Doctrine\DBAL\Types\ConversionException::conversionFailedFormat('2014-12-16 17:0...', 'datetime', 'Y-m-d H:i:s')
  #1 /var/www/vendor/doctrine/orm/lib/Doctrine/ORM/Internal/Hydration/AbstractHydrator.php(330): Doctrine\DBAL\Types\DateTimeType->convertToPHPValue('2014-12-16 17:0...', Object(Doctrine\DBAL\Platforms\MySqlPlatform))
  #2 /var/www/vendor/doctrine/orm/lib/Doctrine/ORM/Internal/Hydration/ObjectHydrator.php(359): Doctrine\ORM\Internal\Hydration\AbstractHydrator->gatherRowData(Array, Array, Array, Array)
  #3 /var/www/vendor/doctrine/orm/lib/Doctrine/ORM/Internal/Hydration/ObjectHydrator.php(179): Doctrine\ORM\Internal\Hydration\ObjectHydrator->hydrateRowData(Array, Array, Array)
  #4 /var/www/vendor/doctrine/orm/lib/Doctrine/ORM/Internal/Hydration/AbstractHydrator.php(140): Doctrine\ORM\Internal\Hydration\ObjectHydrator->hydrateAllData()
  #5 /var/www/vendor/doctrine/orm/lib/Doctrine/ORM/AbstractQuery.php(804): Doctrine\ORM\Internal\Hydration\AbstractHydrator->hydrateAll(Object(Doctrine\DBAL\Driver\PDOStatement), Object(Doctrine\ORM\Query\ResultSetMapping), Array)
  #6 /var/www/vendor/doctrine/orm/lib/Doctrine/ORM/AbstractQuery.php(574): Doctrine\ORM\AbstractQuery->execute(NULL, 1)
  #7 /var/www/index.php(142): Doctrine\ORM\AbstractQuery->getResult()

The solution for MsSQL (see DBAL-860) cannot be used, because the fractional seconds definition can be different across fields:

  `insert` timestamp NULL DEFAULT NULL,
  `update` timestamp(3) NULL DEFAULT NULL,
  `delete` timestamp(5) NULL DEFAULT NULL,

My current approach is to create a custom type, but I would like to create a solution in Doctrine.

Any thoughts on this?



 Comments   
Comment by Marco Pivetta [ 18/Dec/14 ]

We don't currently support this nor can support a change in the DateTime type in 2.x. If you want support for this, then I suggest using a custom type (as you are doing) or proposing something new for 3.x

Comment by Jachim Coudenys [ 19/Dec/14 ]

For anyone that is having the same issue, I've added my version of the custom mapping in a Github Gist.

Comment by Steve Müller [ 24/Dec/14 ]

Jachim Coudenys can you please check if it fixes your issue if you adopted this:

https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Platforms/SQLAnywherePlatform.php#L495-L501

to MysqlPlatform? Because it is basically the same issue. I currently don't have a MySQL 5.6 setup so I cannot test it on my machine.

Comment by Jachim Coudenys [ 31/Dec/14 ]

Steve Müller I think I tried that in the beginning, but normal fields threw errors. I will try it on a VM the following days.





[DBAL-1083] [GH-749] [DBAL-1082] Fix SchemaTool does not generate SQL for MySQL unsigned float Created: 18/Dec/14  Updated: 03/Jan/15  Resolved: 03/Jan/15

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: None
Fix Version/s: 2.6
Security Level: All

Type: Improvement Priority: Minor
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: ddl, decimal, float, mysql, unsinged

Issue Links:
Reference
relates to DBAL-1082 SchemaTool does not generate SQL for ... Resolved

 Description   

This issue is created automatically through a Github pull request on behalf of dchesterton:

Url: https://github.com/doctrine/dbal/pull/749

Message:



 Comments   
Comment by Doctrine Bot [ 03/Jan/15 ]

A related Github Pull-Request [GH-749] was closed:
https://github.com/doctrine/dbal/pull/749





[DBAL-1082] SchemaTool does not generate SQL for MySQL unsigned float Created: 18/Dec/14  Updated: 03/Jan/15  Resolved: 03/Jan/15

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: None
Fix Version/s: 2.6
Security Level: All

Type: Improvement Priority: Minor
Reporter: Daniel Chesterton Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: dbal, ddl, decimal, float, mysql, schematool, unsigned
Environment:

MySQL


Issue Links:
Reference
is referenced by DBAL-1083 [GH-749] [DBAL-1082] Fix SchemaTool d... Resolved

 Description   

The schema update tool does not consider the possibility that MySQL double/float fields can be unsigned.

When running the CLI tool, it recognises that the schemas differ but it doesn't add the appropriate 'UNSIGNED' SQL statement. For example when the database is SIGNED but the entity is marked as UNSIGNED, running the tool with --dump-sql will generate SQL similar to below:

ALTER TABLE tablename CHANGE field field DOUBLE PRECISION NOT NULL;

Running this has no effect on the database and subsequent calls will try to run the same SQL.

I have created a pull request in GitHub which fixes the issue.






[DBAL-1081] Paginator - Query Limit for SQL Server - SqlServerPlatform.php Created: 16/Dec/14  Updated: 29/Dec/14

Status: Open
Project: Doctrine DBAL
Component/s: None
Affects Version/s: 2.5
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Maciej Grajcarek Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: dbal, dql, orderBy, sqlserver
Environment:

Windows



 Description   

Hi!
I have a problem with Query results limit when ordering by SUM of a field.

My query looks like this:

            SELECT ypk.name keyword, SUM(ypk.value) total
            FROM YpBundle:YellowPageKeyword ypk
              JOIN ypk.yellowpage yp
              JOIN yp.listing l
            WHERE l.customer = :customerId
              AND ypk.originDate >= :dateFrom
              AND ypk.originDate <= :dateTo
            GROUP BY ypk.nameCrc, ypk.name
            ORDER BY SUM(ypk.value) DESC

First I was catching following error:
message: "[Syntax Error] line 0, col 395: Error: Expected known function, got 'SUM'"
class: Doctrine\ORM\Query\QueryException

It only accourse if SUM is used in ORDER BY clause.

I have registered new class Sum which extends FunctionNode.

Now, query is build and executed but it has an error:

'SELECT * FROM 
     (SELECT y0_.name AS name_0, SUM(y0_.value) AS sclr_1, ROW_NUMBER() OVER (ORDER BY value) DESC) AS doctrine_rownum FROM yellowpage_keywords y0_ INNER JOIN yellowpages y1_ ON y0_.yellowpage_id = y1_.id INNER JOIN listings l2_ ON y1_.listing_id = l2_.id WHERE l2_.customer_id = ? AND y0_.origin_date >= ? AND y0_.origin_date <= ? GROUP BY y0_.name_crc, y0_.name) AS doctrine_tbl WHERE doctrine_rownum BETWEEN 1 AND 10 ORDER BY doctrine_rownum' with params ["111", "2013-01-01 00:00:00.000000", "2014-12-31 23:59:59.000000"]

The line :

ROW_NUMBER() OVER (ORDER BY value) DESC)

should look like

ROW_NUMBER() OVER (ORDER BY SUM(y0_.value) DESC)

In doModifyLimitQuery method I have modified:

                $pattern = sprintf('/%s\.%s\s+(?:AS\s+)?([^,\s)]+)/i', $column['table'], $column['column']);

to:

                $pattern = sprintf('/%s\.%s\s+(?:AS\s+)?([^,\s)]+)/i', str_replace('(', '\(', $column['table']), str_replace(')', '\)', $column['column']));

Now preg_match founds matching strings and OVER part of query is build correctly.

I checked other issues about this problem (which are marked as already fixed) and I have no idea why it's not working for me.

Thanks in advance!



 Comments   
Comment by Marco Pivetta [ 17/Dec/14 ]

Seems like a bit of information is missing: Is this issue related to the paginator API or not?

Comment by Maciej Grajcarek [ 17/Dec/14 ]

First of all - thank you for formatting my issue.
Secondly yes - issue is directly connected with paginator API.

Here is a code which should help you to replicate the problem:

            SELECT ypk.name keyword, SUM(ypk.value) total
            FROM YpBundle:YellowPageKeyword ypk
              JOIN ypk.yellowpage yp
              JOIN yp.listing l
            WHERE l.customer = :customerId
              AND ypk.originDate >= :dateFrom
              AND ypk.originDate <= :dateTo
            GROUP BY ypk.nameCrc, ypk.name
            ORDER BY SUM(ypk.value) DESC

        $dql = $this->getEntityManager()->createQuery($query);
        $dql
            ->setParameter('customerId', $customerId)
            ->setParameter('dateFrom', $dateFrom)
            ->setParameter('dateTo', $dateTo);
        $dql->setMaxResults(10);    

        $keywords = $dql->getArrayResult(); 
Comment by Marco Pivetta [ 17/Dec/14 ]

That doesn't involve the paginator, just DQL.

SUM() and computed values are not supported in the ORDER BY clause: you have to select them first. Try:

            SELECT ypk.name keyword, SUM(ypk.value) total
            FROM YpBundle:YellowPageKeyword ypk
              JOIN ypk.yellowpage yp
              JOIN yp.listing l
            WHERE l.customer = :customerId
              AND ypk.originDate >= :dateFrom
              AND ypk.originDate <= :dateTo
            GROUP BY ypk.nameCrc, ypk.name
            ORDER BY total DESC
Comment by Maciej Grajcarek [ 18/Dec/14 ]

If I will do it, it will result in a following query:

SELECT *
FROM (
	SELECT y0_.name AS name_0, SUM(y0_.value) AS sclr_1, ROW_NUMBER() OVER (ORDER BY sclr_1 DESC) AS doctrine_rownum 
	FROM yellowpage_keywords y0_
	INNER JOIN yellowpages y1_ ON y0_.yellowpage_id = y1_.id
	INNER JOIN listings l2_ ON y1_.listing_id = l2_.id
	WHERE l2_.customer_id = 111
		AND y0_.origin_date >= '2014-01-01'
		AND y0_.origin_date <= '2014-12-01'
	GROUP BY y0_.name_crc, y0_.name
) AS doctrine_tbl
WHERE doctrine_rownum BETWEEN 1 AND 10
ORDER BY doctrine_rownum

It's an incorrect query for an SQL Server. Take a look on this part:

ROW_NUMBER() OVER (ORDER BY sclr_1 DESC) AS doctrine_rownum

SQL Server do not support aliasing in OVER clause.

It should look like this, to work:

ROW_NUMBER() OVER (ORDER BY SUM(y0_.value) DESC) AS doctrine_rownum

It looks like this is the copy of this issue: http://www.doctrine-project.org/jira/browse/DBAL-788
I'm on doctrine version 2.5 which has patch from that issue included, but I have no idea why it's not working for me.

Comment by Steve Müller [ 24/Dec/14 ]

Maciej Grajcarek looks like it is an issue with your SUM function implementation. If you change your DQL to use ORDER BY COUNT(ypk.value) instead of ORDER BY SUM(ypk.value), does it work then? If so, there is something wrong with your SUM function and therefore not an issue with DBAL.

Comment by Steve Müller [ 24/Dec/14 ]

well forget about it I think I am wrong here.

Comment by Maciej Grajcarek [ 29/Dec/14 ]

Hi,
I will try to use COUNT as soon as I will be able to do that.

But I already tried other aggregation functions before and the result was exactly the same.





[DBAL-1080] [GH-748] minor phpdoc fixes in the remaining files Created: 16/Dec/14  Updated: 24/Dec/14  Resolved: 19/Dec/14

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Documentation Priority: Minor
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Incomplete Votes: 0
Labels: code, cs, phpdoc, style

Issue Links:
Reference
relates to DBAL-1079 [GH-747] minor phpdoc fixes in the sc... Resolved

 Description   

This issue is created automatically through a Github pull request on behalf of acrobat:

Url: https://github.com/doctrine/dbal/pull/748

Message:

This pr fixes the remaining phpcs issues left after #746 & #747



 Comments   
Comment by Doctrine Bot [ 19/Dec/14 ]

A related Github Pull-Request [GH-748] was closed:
https://github.com/doctrine/dbal/pull/748





[DBAL-1079] [GH-747] minor phpdoc fixes in the schema files Created: 16/Dec/14  Updated: 24/Dec/14  Resolved: 24/Dec/14

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: 2.6, 2.5.1
Security Level: All

Type: Improvement Priority: Trivial
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: code, cs, phpdoc, style

Issue Links:
Reference
is referenced by DBAL-1080 [GH-748] minor phpdoc fixes in the re... Resolved

 Description   

This issue is created automatically through a Github pull request on behalf of acrobat:

Url: https://github.com/doctrine/dbal/pull/747

Message:

Some minor phpcs fixes in the dbal schema files



 Comments   
Comment by Doctrine Bot [ 24/Dec/14 ]

A related Github Pull-Request [GH-747] was closed:
https://github.com/doctrine/dbal/pull/747





[DBAL-1078] [GH-746] minor phpdoc fixes in the platform files Created: 16/Dec/14  Updated: 24/Dec/14  Resolved: 16/Dec/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: None
Fix Version/s: 2.6, 2.5.1
Security Level: All

Type: Documentation Priority: Minor
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: code, cs, docblock, style


 Description   

This issue is created automatically through a Github pull request on behalf of acrobat:

Url: https://github.com/doctrine/dbal/pull/746

Message:

Some minor phpcs fixes in the dbal platform files



 Comments   
Comment by Doctrine Bot [ 16/Dec/14 ]

A related Github Pull-Request [GH-746] was closed:
https://github.com/doctrine/dbal/pull/746

Comment by Doctrine Bot [ 16/Dec/14 ]

A related Github Pull-Request [GH-746] was assigned:
https://github.com/doctrine/dbal/pull/746





[DBAL-1077] Query limit for sql server Created: 16/Dec/14  Updated: 21/Feb/15

Status: Open
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: 2.4, 2.5
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: yannick LE LAN Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: dbal, regex, sqlserver
Environment:

sql server



 Description   

On branch master: tests/Doctrine/Tests/DBAL/platforms/AbstractSQLServerPlatformTestCase.php
On branch 2.4: tests/Doctrine/Tests/DBAL/platforms/SqlServerPlatformTest.php

public function testModifyLimitQueryFolcoerr()
{

    $sql = $this->_platform->modifyLimitQuery('SELECT son.label AS Name FROM SqlObjectName son WHERE ( SELECT COUNT(eso.identifier) FROM ExtractedSqlObject eso INNER JOIN ProductionDbName pdn ON eso.ref_ProductionDbName_ID = pdn.identifier AND (pdn.label IN (?, ?)) WHERE eso.ref_SqlObjectName_ID = son.identifier) > 0 ORDER BY son.identifier DESC', 1, 0);

    $this->assertEquals('SELECT * FROM (SELECT son.label AS Name, ROW_NUMBER() OVER (ORDER BY son.identifier DESC) AS doctrine_rownum FROM SqlObjectName son WHERE ( SELECT COUNT(eso.identifier) FROM ExtractedSqlObject eso INNER JOIN ProductionDbName pdn ON eso.ref_ProductionDbName_ID = pdn.identifier AND (pdn.label IN (?, ?)) WHERE eso.ref_SqlObjectName_ID = son.identifier) > 0) AS doctrine_tbl WHERE doctrine_rownum BETWEEN 1 AND 1 ORDER BY doctrine_rownum', $sql);

}

Correction proposed:
on both branches: lib/Doctrine/DBAL/Platforms/SQLServerPlatform.php

protected function doModifyLimitQuery(...)
{
    ...

    #ACTUAL: 
    $selectFromPattern = '/^(\s*SELECT\s+(?:(.*)(?![^(]*\))))\sFROM\s/i';

#CORRECT:

    $selectFromPattern = '/^(\s*SELECT\s+(?:(.*)(?![^(]*\))))\sFROM\s/iU';

explanation: "/U" pattern modifier => http://php.net/manual/en/reference.pcre.pattern.modifiers.php
Ungreedy behavior not susceptible to fall on ?! negative lookahead on parenthesis hunger

  1. has impacts on ORM with setMaxResults (which was failing in my case and made me investigate)


 Comments   
Comment by Marco Pivetta [ 16/Dec/14 ]

Can you send a PR for this change instead?

Comment by yannick LE LAN [ 16/Dec/14 ]

I will do so by the end of the week,

Comment by yannick LE LAN [ 21/Feb/15 ]

Pull requests made:

For dbal version 2.4:
https://github.com/doctrine/dbal/pull/803

For dbal master branch:
https://github.com/doctrine/dbal/pull/804

(as branch 2.4 seems to lack an 'order by' the patch had to be slightly different)





[DBAL-1076] [GH-745] Added doModifyLimitQuery for SQLServer2012Platform that uses OFFSET... FETCH Created: 16/Dec/14  Updated: 24/Dec/14  Resolved: 24/Dec/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: 2.3, 2.4, 2.5
Fix Version/s: 2.6
Security Level: All

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: limit, offset, orderby, server, sql, sqlserver, sqlsrv


 Description   

This issue is created automatically through a Github pull request on behalf of zeroedin-bill:

Url: https://github.com/doctrine/dbal/pull/745

Message:

SQL Server 2012 introduced new syntax for paging records using the OFFSET... FETCH clause. See http://technet.microsoft.com/en-us/library/gg699618%28v=sql.110%29.aspx for details on the specification.

This pull request:

  • Adds doModifyLimitQuery specific to SQLServer2012Platform, using OFFSET ... FETCH instead of ROW_NUMBER() OVER(blah blah)
  • Duplicates tests from SQLServerPlatformTest, using simpler OFFSET ... FETCH syntax

This version of doModifyLimitQuery will be much more robust than the one for SQLServer 2008 and below.



 Comments   
Comment by Doctrine Bot [ 24/Dec/14 ]

A related Github Pull-Request [GH-745] was closed:
https://github.com/doctrine/dbal/pull/745





[DBAL-1075] [GH-744] Removed non-phpdoc @internal tags Created: 15/Dec/14  Updated: 24/Dec/14  Resolved: 16/Dec/14

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: 2.5, 2.4.3
Fix Version/s: 2.6, 2.5.1
Security Level: All

Type: Documentation Priority: Minor
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: annotation, docblock


 Description   

This issue is created automatically through a Github pull request on behalf of acrobat:

Url: https://github.com/doctrine/dbal/pull/744

Message:

Removed 2 @internal phpdoc tags as they were about old internal api usage and these methods are public api as @beberlei & @Ocramius confirmed on irc #doctrine

> ocramius: the @internal are old comments that were used to tell information about internal API usage
> ocramius: they are not the @internal of phpdoc, so you are welcome to send a PR to fix that



 Comments   
Comment by Doctrine Bot [ 16/Dec/14 ]

A related Github Pull-Request [GH-744] was assigned:
https://github.com/doctrine/dbal/pull/744

Comment by Doctrine Bot [ 16/Dec/14 ]

A related Github Pull-Request [GH-744] was closed:
https://github.com/doctrine/dbal/pull/744





[DBAL-1074] [GH-743] Add failing unit test related to DBAL-1063 Created: 14/Dec/14  Updated: 03/Jan/15  Resolved: 03/Jan/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Incomplete Votes: 0
Labels: None

Issue Links:
Reference
is referenced by DBAL-1063 Exceptions from SchemaTool when runni... Resolved

 Description   

This issue is created automatically through a Github pull request on behalf of flack:

Url: https://github.com/doctrine/dbal/pull/743

Message:

I am not 100% sure, but I think the behavior exposed by this test is one of the factors in DBAL-1063. But even if it wasn't, it is still very confusing that `Table::getIndexes` doesn't return the same thing as `SchemaManager::listTableIndexes` when they are both called on the same table.

I've written the test against the MySQL SM, but I suspect the same might happen with other platforms as well



 Comments   
Comment by Doctrine Bot [ 03/Jan/15 ]

A related Github Pull-Request [GH-743] was closed:
https://github.com/doctrine/dbal/pull/743

Comment by Doctrine Bot [ 03/Jan/15 ]

A related Github Pull-Request [GH-743] was assigned:
https://github.com/doctrine/dbal/pull/743

Comment by Doctrine Bot [ 03/Jan/15 ]

A related Github Pull-Request [GH-764] was assigned:
https://github.com/doctrine/dbal/pull/764

Comment by Doctrine Bot [ 03/Jan/15 ]

A related Github Pull-Request [GH-764] was merged:
https://github.com/doctrine/dbal/pull/764





[DBAL-1073] [GH-742] Take care about mariadb platform Created: 12/Dec/14  Updated: 24/Dec/14  Resolved: 24/Dec/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Drivers, Platforms
Affects Version/s: 2.5
Fix Version/s: 2.6, 2.5.1
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: detection, mariadb, mysql, platform, version


 Description   

This issue is created automatically through a Github pull request on behalf of nlegoff:

Url: https://github.com/doctrine/dbal/pull/742

Message:

Hi,
After upgrading to DBAL 2.5, I got an issue where I could not rename index while migrating because of MariaDB [versioning](http://en.wikipedia.org/wiki/MariaDB#Versioning) which outputs ```10.0.15-MariaDB-1~wheezy ``` as server version.

Because 10.x > 5.7 it loads new features from mysql 5.7 which are not available in mariadb ..



 Comments   
Comment by Doctrine Bot [ 13/Dec/14 ]

A related Github Pull-Request [GH-742] was assigned:
https://github.com/doctrine/dbal/pull/742

Comment by Doctrine Bot [ 24/Dec/14 ]

A related Github Pull-Request [GH-742] was closed:
https://github.com/doctrine/dbal/pull/742





[DBAL-1072] [GH-741] [DBAL-1051] Quote index name in inline index declaration SQL Created: 12/Dec/14  Updated: 12/Dec/14  Resolved: 12/Dec/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: None
Fix Version/s: 2.6, 2.5.1
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Reference
relates to DBAL-1051 [GH-730] Update index name quoting in... Resolved

 Description   

This issue is created automatically through a Github pull request on behalf of deeky666:

Url: https://github.com/doctrine/dbal/pull/741

Message:

Supersedes #730

  • Improved test case
  • Fixed quoting for SQL Anywhere
  • Throw exception in DB2 platform for unsupported inline index declarations


 Comments   
Comment by Doctrine Bot [ 12/Dec/14 ]

A related Github Pull-Request [GH-741] was assigned:
https://github.com/doctrine/dbal/pull/741

Comment by Doctrine Bot [ 12/Dec/14 ]

A related Github Pull-Request [GH-741] was closed:
https://github.com/doctrine/dbal/pull/741

Comment by Steve Müller [ 12/Dec/14 ]

Fixed as of https://github.com/doctrine/dbal/commit/558cbf172cb04a9d9df3e11f3425ddf9308e0a81





[DBAL-1071] [GH-740] Add 2.5 status to README Created: 11/Dec/14  Updated: 24/Dec/14  Resolved: 11/Dec/14

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: 2.5, 2.5.1
Fix Version/s: 2.6
Security Level: All

Type: Documentation Priority: Minor
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: badges, travis


 Description   

This issue is created automatically through a Github pull request on behalf of JeroenDeDauw:

Url: https://github.com/doctrine/dbal/pull/740

Message:



 Comments   
Comment by Doctrine Bot [ 11/Dec/14 ]

A related Github Pull-Request [GH-740] was assigned:
https://github.com/doctrine/dbal/pull/740

Comment by Doctrine Bot [ 11/Dec/14 ]

A related Github Pull-Request [GH-740] was closed:
https://github.com/doctrine/dbal/pull/740





[DBAL-1070] AzureSQL specificities are not taken into account Created: 11/Dec/14  Updated: 11/Dec/14

Status: Open
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: 2.5
Fix Version/s: 2.4.3

Type: Bug Priority: Major
Reporter: Nicolas Séverin Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: azure, dbal, sqlserver
Environment:

Azure website using an AzureSQL database (based on SQL Server 2012).



 Description   

In Azure SQL, table ‘sys.extended_properties’ does not exist.
But SQLAzurePlatform inherits from class SQLServerPlatform, which uses it.
The code in question is here /Doctrine/DBAL/Platforms/SQLServerPlatform.php#L845.

Modifications to this portion of code were made to handle comments on columns differently in doctrine/dbal 2.5, but it used to work in 2.4.3.



 Comments   
Comment by Marco Pivetta [ 11/Dec/14 ]

Reverted to priority Major





[DBAL-1069] datetimetz type needs to be a commented one by default Created: 10/Dec/14  Updated: 10/Dec/14

Status: Open
Project: Doctrine DBAL
Component/s: Platforms, Schema Managers
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Christophe Coevoet Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

By default, the AbstractPlatform creates datetimetz fields as datetime field for platforms not defining a specific creation for fields with timezones.
This can be an acceptable fallback if you know that your application always send the value as UTC even when the database can accept any timezone as input thanks to the datetimetz type (database not supporting timezone would still have consistent data if you always send the same timezone).
However it creates an issue for the SchemaTool: the field will obviously be reported as datetime when inspecting the DB, not as datetimetz (since it does not have a datetimetz). So for platforms not supporting datetimetz natively, the special comment should be used to avoid useless updates.
The special Doctrine command should however not be used for platforms supporting the type natively (PostgreSQL, SQLServer2008, Oracle and SqlAnywhere12).

I have an idea about a fix, so I may send a PR for this in the following days.






[DBAL-1068] Microsoft SQL Server issues with ANSI_NULLS=OFF Created: 09/Dec/14  Updated: 13/Dec/14  Resolved: 13/Dec/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: 2.5
Fix Version/s: None
Security Level: All

Type: Bug Priority: Critical
Reporter: man4red Assignee: Steve Müller
Resolution: Invalid Votes: 0
Labels: None
Environment:

Microsoft SQL Server 2012 (11.0.5058)

zf2, doctrine2, skeletonApplication, + modules
zf-commons/zfc-base v0.1.2
zf-commons/zfc-user 1.2.1
zf-commons/zfc-user-doctrine-orm dev-master
bjyoungblood/bjy-authorize dev-master


Attachments: PNG File bug1.png     PNG File bug2.png    

 Description   

So here what I have (see my Environment for more details)

$modules = array(
    'Application', //skeleton
    'DoctrineModule',
    'DoctrineORMModule',
    'DoctrineDataFixtureModule',
    'ZfcBase',
    'ZfcUser',
    'ZfcUserDoctrineORM',
    'BjyAuthorize',
    'User', // Entity copied from BjyAuthorize vendor folder
);
//module/User/Entity/User.php (copied from vendor\bjyoungblood\bjy-authorize\data\User.php.dist)
...
    /**
     * @var string
     * @ORM\Column(type="string", length=255, unique=true, nullable=true)
     */
    protected $username;
...
./vendor/doctrine/doctrine-module/bin/doctrine-module orm:schema-tool:create --dump-sql
CREATE TABLE [users] (id INT IDENTITY NOT NULL, username NVARCHAR(255), email NVARCHAR(255) NOT NULL, displayName NVARCHAR(50), password NVARCHAR(128) NOT NULL, state INT NOT NULL, PRIMARY KEY (id));
CREATE UNIQUE INDEX UNIQ_1483A5E9F85E0677 ON [users] (username) WHERE username IS NOT NULL;
...
and so on...

on create

[Doctrine\ORM\Tools\ToolsException]
Schema-Tool failed with Error 'An exception occurred while executing 'CREATE UNIQUE INDEX UNIQ_1483A5E9F85E0677 ON [users] (username) WHERE username IS NOT NULL':
SQLSTATE[HY000]: General error: 20018 Cannot create index. Object 'users' was created with the following SET options off: 'ANSI_NULLS'. [20018] (severity 16) [CREATE UNIQUE INDEX UNIQ_1483A5E9F85E0677 ON [users] (username) WHERE username IS NOT NULL]' while executing DDL: CREATE UNIQUE INDEX UNIQ_1483A5E9F85E06
77 ON [users] (username) WHERE username IS NOT NULL
....

Maybe this helps:

My database created in MSSQL and has default option ANSI_NULLS = OFF

see my options (bug1.png)

ok, changed it to ANSI_NULLS = ON according to documentation (but for now this sets OFF by default on create database)

got a new exception

[Doctrine\ORM\Tools\ToolsException]
Schema-Tool failed with Error 'An exception occurred while executing 'CREATE UNIQUE INDEX UNIQ_1483A5E9F85E0677 ON [users] (username) WHERE username IS NOT NULL':
SQLSTATE[HY000]: General error: 20018 CREATE INDEX failed because the following SET options have incorrect settings: 'CONCAT_NULL_YIELDS_NULL, ANSI_WARNINGS, ANSI_PADDING'. Verify that SET options are correct for use with indexed views and/or indexes on computed columns and/or filtered indexes and/or query noti
fications and/or XML data type methods and/or spatial index operations. [20018] (severity 16) [CREATE UNIQUE INDEX UNIQ_1483A5E9F85E0677 ON [users] (username) WHERE username IS NOT NULL]' while executing DDL: CREATE UNIQUE INDEX UNIQ_1483A5E9F85E0677 ON [users] (username) WHERE username IS NOT NULL

Then I copied to Microsoft SQL Management Studio code above.
No error!

Then I chcked off this checkbox in SQL Management Studio
(see bug2.png)

and SQL query now failed with almost the same error, but now in Management Studio!

Msg 1934, Level 16, State 1, Line 2
CREATE INDEX failed because the following SET options have incorrect settings: 'CONCAT_NULL_YIELDS_NULL'. Verify that SET options are correct for use with indexed views and/or indexes on computed columns and/or filtered indexes and/or query notifications and/or XML data type methods and/or spatial index operations.

So it seems that problem starts when we set for username unique=true and using MSSQL that trying to create UNIQUE INDEX ... WHERE fieled IS NOT NULL

Some related topics:
ANSI_NULLS
CONCAT_NULL_YIELDS_NULL
ANSI_WARNINGS
ANSI_PADDING
Creating a unique constraint that ignores nulls in SQL Server

Going to move my project to MySQL if this bug are not my fault



 Comments   
Comment by Steve Müller [ 12/Dec/14 ]

This is nothing we can control in Doctrine. According to the documentation http://msdn.microsoft.com/en-us/library/ms189292.aspx there are some requirements server-side that have to be met in order for such unique constraints to work. You will have to configure your server properly.

Comment by man4red [ 12/Dec/14 ]

Yep, thx for answer, but according to the same documentation:

The ANSI_NULLS connection-level option must be set to ON when the CREATE TABLE or ALTER TABLE statement that defines the computed column is executed. The OBJECTPROPERTY function reports whether the option is on through the IsAnsiNullsOn property.

The connection on which the index is created, and all connections trying INSERT, UPDATE, or DELETE statements that will change values in the index, must have six SET options set to ON and one option set to OFF. The optimizer ignores an index on a computed column for any SELECT statement executed by a connection that does not have these same option settings.
The NUMERIC_ROUNDABORT option must be set to OFF, and the following options must be set to ON:
ANSI_NULLS
ANSI_PADDING
ANSI_WARNINGS
ARITHABORT
CONCAT_NULL_YIELDS_NULL
QUOTED_IDENTIFIER
Setting ANSI_WARNINGS to ON implicitly sets ARITHABORT to ON when the database compatibility level is set to 90 or higher.

So my fixtures are created without correct connection-level option

Am I wrong?

Comment by man4red [ 12/Dec/14 ]

I think that problem is still persist.
According to documentation connection must have some options (see http://msdn.microsoft.com/en-us/library/ms189292.aspx and my comment)

Propose to pay more attention to the problem.

Comment by Steve Müller [ 12/Dec/14 ]

Hmmm I suppose that there is something wrong with your setup/configuration then. I just tested this using DBAL + sqlsrv driver + SQL Server 2012 and it adds the unique index on a nullable column without problems. Not sure what's wrong with your client/server setup then. Also I don't see how one would set those settings in the connection handle...
Which database driver are you using? sqlsrv or pdo_sqlsrv?

Comment by man4red [ 12/Dec/14 ]

Sorry for bothering you/
Now I began to suspect that the case in the client
I'll test today booth setup on a diffirent clients

Comment by Steve Müller [ 12/Dec/14 ]

Nevermind
If there truly is a bug we'll fix that somehow but as this is really common core functionality and nobody complained so far I suppose it's really related to your environment. Please let me know if I can close the issue as soon as you have checked your env.
Thanks!

Comment by man4red [ 12/Dec/14 ]

Steve, it seems, that problem persist only with FreeTDS/dblib driver (my env). Probably sqlsrv driver does set this parameters automatically.
Unfortunately there is no other mssql drivers for linux, so situation is very strange. Maybe there is nobody using linux + mssql env? Crzy Also forced to move to pdo_mysql.

Untill dblib not supported for doctrine - we can mark this as invalid.
Thx for your help

Comment by man4red [ 12/Dec/14 ]

Am I right at conclusion that:
1. Linux users can use dblib+mssql and had this issues. To fix this they can set connection-level paramters somehow before ALTER TABLE by querying "SET ANSI_NULLS ON; SET ANSI_PADDING ON; ..." etc...
2. There is only windows users are able to use doctrine DBAL with mssql without any problems thru sqlsrv driver provided by microsoft?
it bothers me in some way

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

Hehe we could have saved a lot of time if you had mentioned earlier that your are using dblib driver
But nevermind. dblib is not supported by Doctrine as it is an experimental driver and quite buggy. Not even sure how you managed to get DBAL connecting through dblib without a custom driver implementation. Whatsoever, unfortunately you are right, there currently is no officially supported way of connecting with DBAL to a SQL Server using a linux client. And yes only Windows users can do that by using either pdo_sqlsrv or native sqlsrv drivers provided by M$
If you are not bound to a Microsoft SQL Server backend and can use an alternative such as MySQL or any other database vendor I would then advise you to do that. I highly discourage you to start messing with dblib and its bugs/incompatibilities. If you are really bound to SQL Server you'll have to let your PHP application run on a windows machine and utilize one of Microsoft's PHP drivers. Hope that helps for now...
Closing then...





[DBAL-1067] mysql: selecting db issue Created: 09/Dec/14  Updated: 09/Dec/14  Resolved: 09/Dec/14

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Miloslav Nenadál Assignee: Marco Pivetta
Resolution: Duplicate Votes: 0
Labels: None

Issue Links:
Duplicate
duplicates DBAL-1057 Connection is not lazy anymore when g... Open

 Description   

When I drop database and create it inside a program, I get error below in case I try to manipulate with db somehow (create table e.g.):

[PDOException]
SQLSTATE[3D000]: Invalid catalog name: 1046 No database selected

This not happens with sqlite3 or postgres - it happens with mysql only.






[DBAL-1066] [GH-738] Define composer test script Created: 09/Dec/14  Updated: 09/Dec/14  Resolved: 09/Dec/14

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of MaxGfeller:

Url: https://github.com/doctrine/dbal/pull/738

Message:

The composer test script is an easy and convenient way to define your unit
testing scripts. It makes testing your library as easy as just running
`composer test`.

For more information about the `scripts` field check out [the manual](https://getcomposer.org/doc/articles/scripts.md) and [this blog post](http://maxgfeller.com/blog/2014/07/22/composer-test/).



 Comments   
Comment by Doctrine Bot [ 09/Dec/14 ]

A related Github Pull-Request [GH-738] was closed:
https://github.com/doctrine/dbal/pull/738

Comment by Doctrine Bot [ 09/Dec/14 ]

A related Github Pull-Request [GH-738] was assigned:
https://github.com/doctrine/dbal/pull/738





[DBAL-1065] sqlite: foreign keys Created: 09/Dec/14  Updated: 09/Dec/14  Resolved: 09/Dec/14

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Miloslav Nenadál Assignee: Marco Pivetta
Resolution: Duplicate Votes: 0
Labels: None

Issue Links:
Duplicate
duplicates DBAL-866 Foreign Key Constraints does not work... Resolved

 Description   

It seems that operations (like listing) are not supported with foreign keys on sqlite.



 Comments   
Comment by Miloslav Nenadál [ 09/Dec/14 ]

the issue you linked is marked as resolved, but this really doesn't work:
https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Platforms/SqlitePlatform.php#L695

because of the line above, when I run:

$connection = $container->get('doctrine.dbal.default_connection');
$schemaManager = $connection->getSchemaManager();
$tables = $schemaManager->listTables();

$foreignKeys = [];
foreach ($tables as $table) {
    $foreignKeys[$table->getName()] = $table->getForeignKeys();
}
var_dump($foreignKeys);

then I would see no foreign keys.

Comment by Marco Pivetta [ 09/Dec/14 ]

The linked issue is resolved as "invalid" because the foreign key support for sqlite was removed due to compatibility problems across sqlite versions.

Closing again.





[DBAL-1064] Duplicate Encoding of column comments in MySQL Created: 06/Dec/14  Updated: 08/Dec/14  Resolved: 08/Dec/14

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: flack Assignee: Steve Müller
Resolution: Invalid Votes: 0
Labels: None


 Description   

I'm not sure if this was done on purpose or not, but I didn't find anything in UPGRADE.md, so I thought I'd file it to be sure:

When I set a column comment that looks like this: "set('auth')", DBAL 2.4 would generate the following SQL:

"CREATE TABLE dummy (settest set('auth') DEFAULT NULL COMMENT 'set('auth')')"

2.5 OTOH create this:

"CREATE TABLE dummy (settest set('auth') DEFAULT NULL COMMENT 'set(''auth'')')"

(the quotes around auth are not double quotes, but two single quotes, in case the font makes it impossible to see).

It is a minor change that I only noticed because one of my unit tests went red, but just by looking at it, the duplicate single quotes seem like an error. Let me know if this is something that should be fixed in DBAL or if I should simpy adjust my test to expect a different result



 Comments   
Comment by Steve Müller [ 08/Dec/14 ]

flack It's automatically escaping string literal delimiters now because using string literal delimiters inside a literal string requires escaping otherwise resulting in invalid SQL.

SQL query:
CREATE TABLE dummy (settest set('auth') DEFAULT NULL COMMENT 'set('auth')')

MySQL said:
#1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'auth')')' at line 1

SQL query:
CREATE TABLE dummy (settest set('auth') DEFAULT NULL COMMENT 'set(''auth'')')

MySQL returned an empty result set (i.e. zero rows). (Query took 0.0147 seconds.)

You have to change your test suite.





[DBAL-1063] Exceptions from SchemaTool when running with DBAL 2.5.0 Created: 06/Dec/14  Updated: 09/Jan/15  Resolved: 03/Jan/15

Status: Resolved
Project: Doctrine DBAL
Component/s: Schema Managers
Affects Version/s: 2.5
Fix Version/s: 2.6, 2.5.1
Security Level: All

Type: Bug Priority: Major
Reporter: flack Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: ddl, foreign-keys, index, schemadiff

Issue Links:
Reference
relates to DBAL-50 PgSQL driver does not create indexes ... Resolved
relates to DBAL-1062 upgrade from v2.4.3 to v2.5.0 is forc... Resolved
relates to DBAL-1074 [GH-743] Add failing unit test relate... Resolved
is referenced by DBAL-1102 [GH-764] [DBAL-1063] Allow defining d... Resolved
is referenced by DDC-3478 [GH-1239] Fix index duplication for u... Resolved
is referenced by DBAL-1108 [GH-769] Allow overriding implicit in... Resolved

 Description   

I'm not entirely sure it it is related to DBAL-1062, but I'm seeing some similar problems since updating to 2.5.0. The problem I'm having occurs only once per table, and only for some tables, so it is kind of hard to debug. What I've found out so far is that it happens when I manually define an index on a column which I name f.x. 'colname_idx', and then later Doctrine wants to add an index to the column automatically (e.g. when it is an association field), in which case it generates an index name like 'IDX_CF2713FD16F4F95B'.

An index with this name already exists (from the last run of the SchemaTool, presumably). The isFullfilledBy function in Doctrine\DBAL\Platforms\AbstractPlatform\Index detects that the both the manually-named index and the automatically-named one are identical and thus ignores them in Doctrine\DBAL\Schema\Table::_addIndex.

When the schema read from the database is compared to the one generated from metadata in Doctrine\DBAL\Schema\Comparator::diffTable, $table1 will list 'colname_idx' and the one from $table2 will say 'IDX_CF2713FD16F4F95B'. So it will be counted as a rename, and the rename SQL (for mysql at least) is

DROP INDEX colname_idx ON tablename
CREATE INDEX IDX_CF2713FD16F4F95B ON tablename (colname)

But as mentioned before, IDX_CF2713FD16F4F95B already exists, so I get

  [Doctrine\DBAL\Exception\DriverException]                                                          
  An exception occurred while executing 'CREATE INDEX IDX_CF2713FD16F4F95B ON tablename (colname)':          
  SQLSTATE[42000]: Syntax error or access violation: 1061 Duplicate key name 'IDX_CF2713FD16F4F95B'

Since the DROP statement before was executed successfully, on the next SchemaTool run, the existing index will be detected correctly for $table1, and thus no rename is issued.



 Comments   
Comment by Steve Müller [ 08/Dec/14 ]

From a first glance this issue is caused by ORM's schema tool which is creating indexes implicitly for unique columns and associations. Seems it doesn't play well with the new index renaming feature from DBAL 2.5 if you also define indexes explicitly that also fullfill those auto generated ones.
Maybe we have to asjust the schema tool to make a certain preference of explicitly defined indexes over auto generated ones if both fullfill the same criteria.

Comment by flack [ 08/Dec/14 ]

Well, making the schema tool smarter is certainly a good idea, since in 2.4 it created duplicate indexes (different name, same function) if I understood your theory correctly.

But there are some things on the DBAL side that I wonder about, e.g. shouldn't dbal do a sanity check before renaming? Or is there one that doesn't trigger because it cannot detect that an index with the target name already exists?

As far as I understood it, the schema read from the database was missing the one index (auto-generated one by SchemaTool), because Doctrine\DBAL\Schema\Table::_addIndex refused to add it on the grounds that it isFullfilledBy the manually-created index. This sounds like a very valid optimization for the case where I plan to write a schema to the database, but it is not at all helpful when creating a representation of an existing database. So I wonder if this case shouldn't be handled differently.

The other thing I'm still unclear about is why the second schema (the one coming from the driver) has the autogenerated index instead of the manual one. I suppose it could be a timing issue, but if the driver and the schematool both were to call _addIndex in the same order, the issue wouldn't even occur. Which might make it difficult to write a unit test for it

Comment by Steve Müller [ 09/Dec/14 ]

flack I did not test anything about this issue yet. It's all just speculation at the moment. What we'll have to do is try reproducing it in a test case. I would propose adding a test case to ORM first as this is your main entry point. Would be awesome if you could PR such a test case that reveals the issue then we can make further inspections. Still not sure whether it's a DBAL or ORM issue or maybe even both...

Comment by flack [ 15/Dec/14 ]

I've added two tests now:

https://github.com/doctrine/dbal/pull/743

The first one shows a discrepancy between Table::getIndexes and SchemaManager::listTableIndexes (which might be the root cause of the problem), and the second one reproduces the exception mentioned above.

BTW: Is there a way to make Jira recognize that a PR belongs to an already existing ticket? Right now, it always seems to create a new issue for each pull request

Comment by Doctrine Bot [ 24/Dec/14 ]

A related Github Pull-Request [GH-756] was assigned:
https://github.com/doctrine/dbal/pull/756

Comment by Doctrine Bot [ 26/Dec/14 ]

A related Github Pull-Request [GH-756] was closed:
https://github.com/doctrine/dbal/pull/756

Comment by Marco Pivetta [ 03/Jan/15 ]

Suggestion: what if we rename indexes only when there is one and exactly one index in the diff before and after? Seems like there is a rename going on in any case right now.

Comment by Marco Pivetta [ 03/Jan/15 ]

BTW: Is there a way to make Jira recognize that a PR belongs to an already existing ticket? Right now, it always seems to create a new issue for each pull request

I've linked the issues together

Comment by flack [ 03/Jan/15 ]

@Marco: The problem with your suggestion is that the diff always only contains one index because of a (IMHO misguided) optimization in Doctrine\DBAL\Schema\Table::_addIndex. This test case shows the problem:

https://github.com/flack/dbal/commit/6ee814939525e15e136c9527c86967fba89860a3#diff-921db63349be598a376afb1584ccc8b5R113

Two indexes are read from the database, but only the first one is added to the Doctrine\DBAL\Schema\Table object, because the second one is discarded because of the isFulfilledBy check. So for the SchemaTool, it always looks like there is one index in DB and one in schema. If both are read in the same order ([index1, index2] from db and schema), then you have no problem. But if they are read in different oder ([index1, index2] from db and [index2, index1] from schema or the other way around), then the Exception hits.

Comment by Marco Pivetta [ 03/Jan/15 ]

The problem is indeed https://github.com/doctrine/dbal/blob/89d4f06fb4ff6e7b8f3c29a7307bf66203e09922/lib/Doctrine/DBAL/Schema/Table.php#L492-L497, which was introduced because of reasons explained in https://github.com/doctrine/dbal/blob/89d4f06fb4ff6e7b8f3c29a7307bf66203e09922/lib/Doctrine/DBAL/Schema/Table.php#L541-L543.

That logic should be manually triggered instead of implicitly executed every time.

Comment by Doctrine Bot [ 03/Jan/15 ]

A related Github Pull-Request [GH-743] was closed:
https://github.com/doctrine/dbal/pull/743

Comment by Doctrine Bot [ 03/Jan/15 ]

A related Github Pull-Request [GH-743] was assigned:
https://github.com/doctrine/dbal/pull/743





[DBAL-1062] upgrade from v2.4.3 to v2.5.0 is forcing recreating Indexes making Doctrine unusable Created: 05/Dec/14  Updated: 13/Jan/15  Resolved: 26/Dec/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: 2.5
Fix Version/s: 2.6, 2.5.1

Type: Bug Priority: Major
Reporter: gondo Assignee: Steve Müller
Resolution: Fixed Votes: 1
Labels: index, rename
Environment:

any


Issue Links:
Reference
is referenced by DBAL-1063 Exceptions from SchemaTool when runni... Resolved
is referenced by DBAL-1092 [GH-756] [DBAL-1062] Fix renaming ind... Resolved

 Description   

after executing 'composer update' i was upgraded to dbal v2.5.0
(im using "doctrine/orm": "~2.2,>=2.2.3" in composer.json)
im using Symfony 2.6.*

now when i try 'app/console doctrine:schema:update --dump-sql' i see that doctrine wants to recreate indexes on some tables for no practical reason
nothing changed in the code.

example:
DROP INDEX idx_a604da13a76ed395 ON table1;
CREATE INDEX IDX_B7E704F0A76ED395 ON table1 (user_id);
DROP INDEX uniq_b3319c7d77153098 ON table2;
CREATE UNIQUE INDEX UNIQ_C984F95777153098 ON table2 (code);

however when i try to execute this update, im getting this error:
General error: 1553 Cannot drop index 'IDX_A604DA13A76ED395': needed in a foreign key constraint

this essentially prevents me from using automatic doctrine database mapping or using migration tools.



 Comments   
Comment by Marco Pivetta [ 05/Dec/14 ]

Downgraded to "Major", as this doesn't prevent usage of the DBAL at runtime.

You can still upgrade those indexes manually after having removed the FKs (to re-add them later on).

Seems like a case sensitivity issue of your setup: consider adding environment details.

Comment by Steve Müller [ 05/Dec/14 ]

Which database vendor are you using? Also interestingly the indexes get recreated with a different name. Thought of case sensitivity, too. I think the comparator nevertheless has to be adjusted to compare with identical case on index names.

Comment by gondo [ 05/Dec/14 ]

well it IS preventing me from using doctrine as it is.
i just downgraded dbal to v2.4.3 by adding "doctrine/dbal": "2.4.*", to my composer.js and everything is working fine. by that i mean, no commands to drop and create indexes.

im using mysql Ver 14.14 Distrib 5.6.21, for osx10.10 (x86_64) using EditLine wrapper

im developoing on OSX 10.10 and production is running CentOS.
i know that OSX is using case insensitive file system (i had to deal with it in the past when i was deploying to production)
but this time there is NO change in my code. zero. nothing.

if there was case sensitivity changes in dbal itself, that might be the problem, however that is nothing i can fix.

i would love to upgrade those indexes manualy, however i have no idea how to.
should i change something in the code? indexes were created and named by doctrine, not by me.
if you recommend updating database, that seems to be failing. i assume dropping indexes on live data might cause problems.
or is it safe to just drop and create these indexes in mysql cmd?

Comment by gondo [ 05/Dec/14 ]

i can not drop those indexes directly in mysql, im getting erros:
ERROR 1553 (HY000): Cannot drop index 'IDX_A604DA13A76ED395': needed in a foreign key constraint

Comment by Steve Müller [ 05/Dec/14 ]

okay just checked, casing is not a problem as identifiers will be lowercased automatically in Doctrine\DBAL\Schema\Table for comparison.
Need further information about the underlying database being used...

Comment by Steve Müller [ 05/Dec/14 ]

gondo please for now don't try to solve the issue automatically because it looks like a real issue we need to figure out. Otherwise there will be little chance we get to know the real cause of the issue...

Comment by gondo [ 05/Dec/14 ]

@Steve Müller for now i've solved it by downgrading dbal to v2.4.*
do you need some more information from me?
unfortunately i can't give you all the code, company policy + its quite big. but i can dump you database schemas and entity declarations of affected tables if that will help. please let me know.

Comment by Steve Müller [ 05/Dec/14 ]

Hmm cannot reproduce the problem. What I did:

composer create-project symfony/framework-standard-edition path/

then added 'doctrine/dbal": "2.4.*"' to composer.json

composer install

then created entity with unique column name (to force auto index generation)

php app/console doctrine:database:create
php app/console doctrine:schema:create

then changed 'doctrine/dbal": "2.4."' to 'doctrine/dbal": "2.5."' in composer.json

php app/console doctrine:schema:update --force
Nothing to update - your database is already in sync with the current entity metadata.

Tried that with pdo_mysql on ubuntu 14.04 x86_64.

Comment by gondo [ 05/Dec/14 ]

were you creating some tables with foreign keys?

Comment by gondo [ 05/Dec/14 ]

here is the list of all indexes what tries to be recreated:
http://pastebin.com/nFYp6pnp

here are the definitions of some entities + their schemas and indexes from mysql:
notification_channel
http://pastebin.com/EfkcyUnf
http://pastebin.com/Ngd1Lkbe

online_payment_option
http://pastebin.com/R5waCF35
http://pastebin.com/ti4TzyKX

user_settings
http://pastebin.com/gxed5kjY
http://pastebin.com/EiCBWKNQ

i've also tried to specify index with custom name as per http://doctrine-orm.readthedocs.org/en/latest/reference/annotations-reference.html#annref-index
to prevent this index recreation but without no luck, it was ignored.
i've tried to change the definition of `online_payment_option` table like this:
@ORM\Table(name="online_payment_option", options=

{"collate"="utf8_unicode_ci", "charset"="utf8"}

, indexes={@ORM\Index(name="TEST", columns=

{"code"}

)})
but after trying schema:update im still getting the same output http://pastebin.com/nFYp6pnp

Comment by Steve Müller [ 12/Dec/14 ]

Okay I think I get the problem now. I don't get any suggested update statements when upgrading from a DBAL 2.4 created schema to DBAL 2.5.
I assume this is because even in DBAL 2.4 the indexes are created with the name your update command suggests. For example:

DROP INDEX idx_a604da13a76ed395 ON notification_channel;
CREATE INDEX IDX_B7E704F0A76ED395 ON notification_channel (user_id);

You have an index named idx_a604da13a76ed395 in your database, the index name DBAL generates is IDX_B7E704F0A76ED395. Even in 2.4 this is the name that is generated by DBAL. The reason why you get those update statements is because index names are compared since DBAL 2.5 as part of the new index renaming feature.
I guess that the index name generation has changed in an earlier version of DBAL (can't prove that right now). So you probably created the index with a much earlier DBAL version back then and now it wants to rename it. This should be a one time "upgrade" step.
The reason why manually defining an index in your entity with a custom name has no effect is because ORM's schema tool prefers auto generated indexes over custom indexes if both fullfill the same criteria. This is something to be fixed in ORM then.
The foreign key problem is indeed something we have to deal with in DBAL. The update schema command should create SQL to first drop FKs, then rename indexes and afterwards recreate FKs again.
Hope that helps for now. Sorry for the upgrade circumstances...

Comment by gondo [ 12/Dec/14 ]

thank you very much for looking into this and spending time on it!
it is very likely that those indexes were created in older version, however I'm 100% that it is not older than 1 year.

if i understand correctly, there are several things what needs to be fixed (manual overwriting of indexes and generating proper update schema command)

is this something what will be fixed? or does this fall into "edge case" bucket and will be left until more people experience same problem?
so far I'm fine staying on 2.4.3 but eventually i would like to upgrade. if the fix is planned, i can wait. if not, than i can create manual update now.

thanks one more time

Comment by Steve Müller [ 12/Dec/14 ]

I am already on that foreign key issue. As soon as that is fixed, the generated update SQL should be valid so that it can safely be run and you don't need to update your index names manually then. As what the manual index preference is concerned that needs to be fixed in ORM. I might also have a look into this issue afterwards. I think it won't take long until DBAL 2.5.1 as there is another critical issue that needs to be adressed sonner than later.
With 2.5.1 you should be safe to update your schema automatically.

Comment by gondo [ 12/Dec/14 ]

perfect!
thats much sooner than i expected
thanks again

Comment by Gábor Tóth [ 22/Dec/14 ]

This is a deal breaker for us. We cannot use 2.5 branch until it is not fixed.

Comment by Marco Pivetta [ 22/Dec/14 ]

Gábor Tóth you are not forced to upgrade for now: consider sending a patch if it is that critical to you.

Comment by Steve Müller [ 24/Dec/14 ]

Gábor Tóth I provide a patch here: https://github.com/doctrine/dbal/pull/756

Comment by Doctrine Bot [ 26/Dec/14 ]

A related Github Pull-Request [GH-756] was closed:
https://github.com/doctrine/dbal/pull/756

Comment by gondo [ 13/Jan/15 ]

i've just updated to 2.5.1 and the problem remains

Comment by Steve Müller [ 13/Jan/15 ]

gondo can you please post the SQL created by the schema tool and the error you get? Thanks.

Comment by gondo [ 13/Jan/15 ]

same as on the beginning, basically nothing changed for me :/
http://pastebin.com/NqP9aEae

Comment by Steve Müller [ 13/Jan/15 ]

Do you get an error when executing the SQL? I can see that foreign keys are now dropped before dropping and recreating the index which is part of the patch. The reason why the schema manager is still outputting upgrade SQL was discussed here before (index name mismatch). However this should only happen once now and it should work without an error.

Comment by gondo [ 13/Jan/15 ]

ah i see.
i was expecting that there will be no SQL update needed after this patch, but now i understand what you mean.
i was only doing `app/console doctrine:schema:update --dump-sql`
after trying `app/console doctrine:schema:update --force` (on localhost only) everything seems to be fine

perfect! i will do some more testing, hopefully i ll not destroy production database with this

Comment by Steve Müller [ 13/Jan/15 ]

Unfortunately we cannot prevent SQL generation for users that have different index names in their database than those created by the mapping. Those users will have to "resync" index names once and should be fine afterwards. If we would not compare index names, the index renaming feature would not be possible.
You should be safe to run the SQL in production as it is just dropping and recreating indexes / foreign keys.





[DBAL-1061] [GH-737] [DBAL-1058] [2.4] Fix database names introspection for SQL Server Created: 05/Dec/14  Updated: 12/Jan/15  Resolved: 12/Jan/15

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms, Schema Managers
Affects Version/s: 2.4
Fix Version/s: 2.4.4
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Reference
relates to DBAL-1058 It seems that MSSQL syntax was changed Resolved
relates to DBAL-1060 [GH-736] [DBAL-1058] Fix database and... Resolved

 Description   

This issue is created automatically through a Github pull request on behalf of deeky666:

Url: https://github.com/doctrine/dbal/pull/737

Message:

Backport of #736 to 2.4 branch.



 Comments   
Comment by Doctrine Bot [ 05/Dec/14 ]

A related Github Pull-Request [GH-737] was assigned:
https://github.com/doctrine/dbal/pull/737

Comment by Doctrine Bot [ 12/Jan/15 ]

A related Github Pull-Request [GH-736] was merged:
https://github.com/doctrine/dbal/pull/736

Comment by Doctrine Bot [ 12/Jan/15 ]

A related Github Pull-Request [GH-737] was merged:
https://github.com/doctrine/dbal/pull/737





[DBAL-1060] [GH-736] [DBAL-1058] Fix database and namespace introspection for SQL Server Created: 05/Dec/14  Updated: 12/Jan/15  Resolved: 12/Jan/15

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms, Schema Managers
Affects Version/s: 2.4, 2.5
Fix Version/s: 2.6, 2.5.1
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Reference
relates to DBAL-1058 It seems that MSSQL syntax was changed Resolved
is referenced by DBAL-1061 [GH-737] [DBAL-1058] [2.4] Fix databa... Resolved

 Description   

This issue is created automatically through a Github pull request on behalf of deeky666:

Url: https://github.com/doctrine/dbal/pull/736

Message:

It looks like some SQL Server versions / setups need system tables to be queried lowercased otherwise causing errors.



 Comments   
Comment by Doctrine Bot [ 05/Dec/14 ]

A related Github Pull-Request [GH-736] was assigned:
https://github.com/doctrine/dbal/pull/736

Comment by Doctrine Bot [ 05/Dec/14 ]

A related Github Pull-Request [GH-737] was assigned:
https://github.com/doctrine/dbal/pull/737

Comment by Doctrine Bot [ 12/Jan/15 ]

A related Github Pull-Request [GH-736] was merged:
https://github.com/doctrine/dbal/pull/736

Comment by Doctrine Bot [ 12/Jan/15 ]

A related Github Pull-Request [GH-737] was merged:
https://github.com/doctrine/dbal/pull/737





[DBAL-1059] [GH-735] Bump version 2.6.0-DEV Created: 05/Dec/14  Updated: 05/Dec/14  Resolved: 05/Dec/14

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: 2.6
Security Level: All

Type: Task Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: release, version


 Description   

This issue is created automatically through a Github pull request on behalf of deeky666:

Url: https://github.com/doctrine/dbal/pull/735

Message:

/cc @Ocramius @beberlei



 Comments   
Comment by Doctrine Bot [ 05/Dec/14 ]

A related Github Pull-Request [GH-735] was assigned:
https://github.com/doctrine/dbal/pull/735

Comment by Doctrine Bot [ 05/Dec/14 ]

A related Github Pull-Request [GH-735] was closed:
https://github.com/doctrine/dbal/pull/735





[DBAL-1058] It seems that MSSQL syntax was changed Created: 05/Dec/14  Updated: 29/Jan/15  Resolved: 12/Jan/15

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: 2.4, 2.5
Fix Version/s: 2.4.4, 2.6, 2.5.1

Type: Bug Priority: Blocker
Reporter: man4red Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: dbal, sqlserver

Issue Links:
Reference
is referenced by DBAL-1060 [GH-736] [DBAL-1058] Fix database and... Resolved
is referenced by DBAL-1061 [GH-737] [DBAL-1058] [2.4] Fix databa... Resolved

 Description   

I'm using dblib, MSSQL (2012).
So, problem is here:

doctrine-module orm:schema-tool:update --dump-sql

Doctrine\DBAL\Driver\PDOException: SQLSTATE[HY000]: General error: 20018 Invalid object name 'SYS.SCHEMAS'. [20018] (severity 16) [SELECT name FROM SYS.SCHEMAS WHERE name NOT IN('guest', 'INFORMATION_SCHEMA', 'sys')] in /var/www/domains/internal.dc.hayas.ru/data/partners.zf2/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php on line 106

So it seems, that problems is here:

Doctrine\DBAL\Platforms\SQLServerPlatform.php
At Line 1036

    public function getListNamespacesSQL()
    {
        return "SELECT name FROM SYS.SCHEMAS WHERE name NOT IN('guest', 'INFORMATION_SCHEMA', 'sys')";
    }

SQL Server >= 2005 uses sys.schemas (lowercase)

Maybe need to add to SQLServer2005Platform.php

SELECT name FROM sys.schemas ...

and also at line 1028 SQLServerPlatform.php

    public function getListDatabasesSQL()
    {
        return 'SELECT * FROM SYS.DATABASES';
    }

add to SQLServer2005Platform.php

    public function getListDatabasesSQL()
    {
        return 'SELECT * FROM sys.databases';
    }


 Comments   
Comment by Steve Müller [ 05/Dec/14 ]

man4red thanks for reporting. I'll have a look at it this evening. Weird that the functional tests pass though in my setup :S

Comment by Marco Pivetta [ 05/Dec/14 ]

Steve Müller please note that he is using dblib, which (afaik) we do not officially support.

Comment by man4red [ 05/Dec/14 ]

I've checked by direct query to SQL via SQL Management Studio.
Got multiple servers with a diffirent versions.

Here some test

QUERY:

 SELECT name FROM SYS.SCHEMAS WHERE name NOT IN('guest', 'INFORMATION_SCHEMA', 'sys') 

9.0.5069 (SQL Server 2005 Service Pack 4) PASS
10.50.4000.0 (2008 R2 SP2) FAIL
11.0.5058 (SQL Server 2012) FAIL

QUERY:

SELECT name FROM sys.schemas WHERE name NOT IN('guest', 'INFORMATION_SCHEMA', 'sys')

9.0.5069 (SQL Server 2005 Service Pack 4) PASS
10.50.4000.0 (2008 R2 SP2) PASS
11.0.5058 (SQL Server 2012) PASS

I've tested on 5 servers 11.0.5058 (SQL Server 2012).
QUERY:

SELECT name FROM SYS.SCHEMAS WHERE name NOT IN('guest', 'INFORMATION_SCHEMA', 'sys')

Failed on each of them

Other tests:

QUERY:

SELECT * FROM SYS.DATABASES

9.0.5069 (SQL Server 2005 Service Pack 4) PASS
10.50.4000.0 (2008 R2 SP2) PASS
11.0.5058 (SQL Server 2012) PASS

QUERY:

SELECT * FROM sys.databases

9.0.5069 (SQL Server 2005 Service Pack 4) PASS
10.50.4000.0 (2008 R2 SP2) PASS
11.0.5058 (SQL Server 2012) PASS

by the way - is it neccessary to query * from SYS.DATABASES ?

Doctrine\DBAL\Platforms\SQLServerPlatform.php

Line 1030

    public function getListDatabasesSQL()
    {
        return 'SELECT * FROM SYS.DATABASES';
    }

Maybe need to query only names? (name field)
Just asking

Comment by man4red [ 05/Dec/14 ]

According to tests I've added next code to SQLServer2008Platform.php

    /**
     * {@inheritDoc}
     */
    public function getListNamespacesSQL()
    {
        return "SELECT name FROM sys.schemas WHERE name NOT IN('guest', 'INFORMATION_SCHEMA', 'sys')";
    }

And modified my ZF2 application doctrine config config/autoload/doctrine.local.php (platform added):

return array(
    'doctrine' => array(
        'connection' => array(
            'orm_default' => array(
                'driverClass' => 'class to work with dblib',
                'params' => array(
                    'host' => 'hostname',
                    'port' => 1433,
                    'user' => 'user',
                    'password' => 'pass',
                    'dbname' => 'database',
                    'platform' => new Doctrine\DBAL\Platforms\SQLServer2012Platform()
                )
            )
        )
    )
);

Now I've got no issues with MSSQL 2012
I hope my fix was correct

Comment by Steve Müller [ 05/Dec/14 ]

Patch provided: https://github.com/doctrine/dbal/pull/736

Comment by Doctrine Bot [ 05/Dec/14 ]

A related Github Pull-Request [GH-736] was assigned:
https://github.com/doctrine/dbal/pull/736

Comment by man4red [ 05/Dec/14 ]

Dear friends,

I'm new here, and I don't know how all this works here, but can you help me?
As always when one bug fixed - another two produced

Now I've got another problem.
ZendDeveloperTool throws Exception

Uncaught exception 'PDOException' with message 'You cannot serialize or unserialize PDO instances'

of course because of my

    'platform' => new Doctrine\DBAL\Platforms\SQLServer2012Platform()

ok... my mistake

let's fix it in ZF2 way

    'platform' => 'Doctrine\DBAL\Platforms\SQLServer2012Platform'

Now we got another exception:

Doctrine\DBAL\DBALException: Invalid 'platform' option specified, need to give an instance of \Doctrine\DBAL\Platforms\AbstractPlatform.

let's look to doctrine\dbal\lib\Doctrine\DBAL\Connection.php Line: 387

    private function detectDatabasePlatform()
    {
        ...
        } elseif ($this->_params['platform'] instanceof Platforms\AbstractPlatform) {
            $this->platform = $this->_params['platform'];
        } else {
            throw DBALException::invalidPlatformSpecified();
        }
        ...
    }

So my question is

Can we implemet a feature and change this

    private function detectDatabasePlatform()
    {
        if ( ! isset($this->_params['platform'])) {
            $version = $this->getDatabasePlatformVersion();

            if (null !== $version) {
                $this->platform = $this->_driver->createDatabasePlatformForVersion($version);
            } else {
                $this->platform = $this->_driver->getDatabasePlatform();
            }
        } elseif ($this->_params['platform'] instanceof Platforms\AbstractPlatform) {
            $this->platform = $this->_params['platform'];
        } else {
            throw DBALException::invalidPlatformSpecified();
        }

        $this->platform->setEventManager($this->_eventManager);
    }

to this (or similar)

    private function detectDatabasePlatform()
    {
        if (! isset($this->_params['platform'])) {
            $version = $this->getDatabasePlatformVersion();

            if (null !== $version) {
                $this->platform = $this->_driver->createDatabasePlatformForVersion($version);
            } else {
                $this->platform = $this->_driver->getDatabasePlatform();
            }
        } elseif ($this->_params['platform'] instanceof Platforms\AbstractPlatform) {
            $this->platform = $this->_params['platform'];
        } elseif (is_subclass_of($this->_params['platform'], 'Doctrine\DBAL\Platforms\AbstractPlatform')) {
            $this->platform = new $this->_params['platform']();
        } else {
            throw DBALException::invalidPlatformSpecified();
        }

        $this->platform->setEventManager($this->_eventManager);
    }

or this problem is only mine and I need to fix it by my self and to write some forks/mods etc?

Thx for your help anyway

Comment by Marco Pivetta [ 05/Dec/14 ]

man4red that seems to be related with DBAL-1057 - I'll mark this issue as resolved.

Comment by man4red [ 05/Dec/14 ]

Marco Pivetta, thx! Is there planned some big reworking of this section, am I right?
Am I need to post my last comment to DBAL-1057 thread?

Comment by Marco Pivetta [ 05/Dec/14 ]

man4red this section needs some work for 2.5.1, yes. As for posting to DBAL-1057, please do, but only the bits that may be relevant and that you feel that add up to the discussion without cluttering it.

Comment by Doctrine Bot [ 12/Jan/15 ]

A related Github Pull-Request [GH-736] was merged:
https://github.com/doctrine/dbal/pull/736

Comment by Marco Pivetta [ 12/Jan/15 ]

Fixed in DBAL-1060

Comment by Doctrine Bot [ 23/Jan/15 ]

A related Github Pull-Request [GH-783] was closed:
https://github.com/doctrine/dbal/pull/783

Comment by Doctrine Bot [ 29/Jan/15 ]

A related Github Pull-Request [GH-783] was closed:
https://github.com/doctrine/dbal/pull/783





[DBAL-1057] Connection is not lazy anymore when guessing the platform is necessary Created: 05/Dec/14  Updated: 16/Jan/15

Status: Open
Project: Doctrine DBAL
Component/s: Drivers, Platforms
Affects Version/s: 2.5
Fix Version/s: None
Security Level: All

Type: Bug Priority: Critical
Reporter: Christophe Coevoet Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 8
Labels: None

Issue Links:
Duplicate
is duplicated by DBAL-1067 mysql: selecting db issue Resolved
Reference
is referenced by DDC-3475 Avoid db connection in constructor Open

 Description   

In DBAL 2.5, many driver can rely on different versions of the platform. Unless the version is explicitly provided, the driver will guess it at instantiation time, killing the lazyness of the connection.
This is a critical issue in any context using DI as it means that injecting the connection into anything else will connect to the server.



 Comments   
Comment by Christophe Coevoet [ 05/Dec/14 ]

Actually, the Connection class itself defers the guessing until the first time the platform is accessed. But many places in DBAL and in the ORM are retrieving the platform and storing it in a property of the class at instantiation time to avoid method calls when they need to access the platform. So this might be much harder to fix

Comment by Steve Müller [ 05/Dec/14 ]

Christophe Coevoet Can we analyze the use cases where retrieving the platform is necessary before actually connecting? I only know the custom type registering so far... Maybe we can defer that somehow?

Comment by Christophe Coevoet [ 05/Dec/14 ]

Steve Müller the issue is that many places in DBAL and the ORM are retrieving the connection before they use it. the Connection class itself in DBAL is already deferring the guessing

Comment by Steve Müller [ 05/Dec/14 ]

Christophe Coevoet I know that. The question is WHY do those defered connections need to access Connection::getDatabasePlatform() without connecting? What are the use cases?

Comment by Christophe Coevoet [ 05/Dec/14 ]

Steve Müller The issue is that all those objects are calling $connection->getDatabasePlatform() in their own constructor to store a reference to it for faster access later (no more method calls). This means that *instantiating* the ORM (or some parts of DBAL) triggers the platform guessing, which connects to the DB. This breaks the lazyness and hurts DI contexts (maybe the ORM will not even be used in this process, but it was instantiated because of being a dependency in a complex object graph).

Comment by Christophe Coevoet [ 05/Dec/14 ]

and the issue is precisely that all these parts of Doctrine are *not* deferring the retrieval of the platform.

Comment by Steffen Brem [ 07/Dec/14 ]

This is causing a lot of issues when using CI servers. Where it is very important that those things are lazy, since you do not have the database configured on most applications that build on a CI server.

Comment by Craig Heydenburg [ 01/Jan/15 ]

This is also an issue for the project I am working as I am trying to use Symfony to to generate forms and so on in order to install the project. sForms and the main project's front controller trigger DI events and trigger this error. The workaround mentioned here (https://github.com/doctrine/DoctrineBundle/issues/351#issuecomment-65771528) fixes the problem but this cannot be a long term solution. I look forward to the fix for this issue.

Comment by Alan Hartless [ 07/Jan/15 ]

I have the same issue as Craig. This poses a major hassle for applications that have an installer UI. We have a Symfony based application that gives the user options to configure the database such as driver, table, credentials, etc. Then the application will make a dynamic connection to check database, install data, etc. Eventually Symfony's cache is cleared to use the new credentials post install.

Because of this, the installer fails out of the box since it can't connect to the server.

We can't use the work around as mentioned above because of giving the option to choose what driver to use in the installer.

Thanks,
Alan

Comment by Craig Heydenburg [ 14/Jan/15 ]

Tried an experiment today. As noted in the workaround you can set the server_version: 5.1 (or whatever your version is).

Well, my version is 5.5 so I originally used that. Today I tried 5 and 52 and 1 and they all worked!

so it seems that the actual version doesn't matter (at least when I need them, which is before I've actually set up the DB credentials) as long is there is some value.

Comment by Steve Müller [ 15/Jan/15 ]

Craig Heydenburg this is expected behaviour. You can theoretically specify any value you want, DBAL will try to find the appropriate platform for you by the specified version via version compare.
See the example for PostgreSQL: https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Driver/AbstractPostgreSQLDriver.php#L97-L119
As soon as the specified value/version does not match a specific platform version, DBAL will always fallback to the "default" platform (the one that was chosen by default prior 2.5).
Once the serverVersion parameter is set, auto detection of the proper platform is always bypassed.

Comment by Jan Rosier [ 16/Jan/15 ]

Doctrine now also throws a connection exception when it tries to detect the database platform, but can't make a connection to the server. Even if the connection isn't really used.

I think it would be better to do a fallback to the "default" platform in that case and only throw an connection exception if the connection is required for something else than guessing the platform.

For example if you haven't set up the DB credentials yet and only call Doctrine\DBAL\Connection::getDatabasePlatform() you get the "default" platform.





[DBAL-1056] [GH-734] Sign release tags in ant build script Created: 04/Dec/14  Updated: 05/Dec/14  Resolved: 05/Dec/14

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: 2.5
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of deeky666:

Url: https://github.com/doctrine/dbal/pull/734

Message:

/cc @beberlei






[DBAL-1055] doctrine:schema:update SchemaException Created: 04/Dec/14  Updated: 08/Dec/14  Resolved: 08/Dec/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Danilo Henrique Fonseca Menezes Assignee: Steve Müller
Resolution: Invalid Votes: 0
Labels: dbal, schematool


 Description   

I'm trying to run doctrine:schema:update

and a have been thrown this exception

[Doctrine\DBAL\Schema\SchemaException]
The table with name 'name.dbo' already exists.

There are at least two entities with the following mapping structure for the Table name:

/**
 * NotaLancamento
 *
 * @Table(name="name.dbo.notalancamento")
 * @Entity
 */
class NotaLancamento

I'm using MSSQL and the database_name parameter for the connection is a has a different name (for example, name2). In my project I need to access data on the database 'name' and 'name2' at the same time, and they both have the schema dbo, I've been trying to solve this problem for a while. I searched on stackoverflow but got no answers.

Any ideas about what should I do?



 Comments   
Comment by Danilo Henrique Fonseca Menezes [ 04/Dec/14 ]

Going up on the exception stack trace I found out that the
/Doctrine/DBAL/Schema/AbstractAsset.php in its _setName method introduces the problem:

protected function _setName($name)
    {
        if ($this->isIdentifierQuoted($name)) {
            $this->_quoted = true;
            $name = $this->trimQuotes($name);
        }
        if (strpos($name, ".") !== false) {
            $parts = explode(".", $name);
            $this->_namespace = $parts[0];
            $name = $parts[1];
        }
        $this->_name = $name;
    }

It assumes that the namespace+name of the table should have only one dot.

Comment by Steve Müller [ 08/Dec/14 ]

Danilo Henrique Fonseca Menezes DBAL always assumes that you operate on one database at the time. The Schema class refers to exactly one database. So you cannot map entities for multiple databases with the same entity manager / connection. This is currently not supported.

See also here: http://stackoverflow.com/questions/15389692/cross-database-joins-with-doctrine-in-php

We might reconsider supporting this in 3.x but we cannot add support for this in 2.x as it would have to many implications on all dependent projects. So closing this for now.

Comment by Danilo Henrique Fonseca Menezes [ 08/Dec/14 ]

Steve Müller, thank you for your information, I had already read the stackoverflow article you mentioned and I was trying to overcome the problem.

Anyway, thank you so much and I hope to see this feature on doctrine 3.

Comment by Steve Müller [ 08/Dec/14 ]

You're welcome. We might add more schema object layers in 3.0 to make things like this work. Basically what I want to have in 3.0 is the possibility to retrieve the complete schema objects that exist on a single physical database instance which can be queried with one connection and abstract that into different schema layers (table -> schema -> catalog -> cluster — according to the SQL-92 standard definition). But 3.0 is not planned yet so it will take awhile until this might be possible





[DBAL-1054] Expose native database handler from Connection Created: 03/Dec/14  Updated: 03/Dec/14

Status: Open
Project: Doctrine DBAL
Component/s: Drivers
Affects Version/s: 2.4.3
Fix Version/s: None
Security Level: All

Type: Improvement Priority: Trivial
Reporter: Davide Romanini Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: None


 Description   

DBAL drivers totally hide the wrapped native connection handler. Sometimes it is useful having a way to access it, eg: integrating old non-dbal code sharing the same connection, or to access specific funcionalities not available through the driver.
With oci8 for example I'd want to use oci_set_client_info/oci_set_module_name/oci_set_action on postConnect for better dba auditing and analysis. In current implementation the only way is to use reflection and access the protected $dbh instance variable, that's very fragile.
I propose to add a Connection::getNativeConnection() or similar name for this purpose and trivially implement it on the various drivers. BC compatibility could be an issue here, but eventually it could be factored in a more specific interface.



 Comments   
Comment by Steve Müller [ 03/Dec/14 ]

Davide Romanini which Connection are you refering to? The DBAL Connection class provides a getWrappedConnection() method which returns the underlying driver connection object.
If you refer to driver connections in the first place I doubt we will expose the internal connection ressource to avoid possible weird side effects. We had similar discussion several times now. If you need advanced access to driver specific functionality on the connection, please don't use DBAL. DABL is about abstraction accross different drivers and database vendors. It is not intended for advanced driver specific usage.

Comment by Davide Romanini [ 03/Dec/14 ]

getWrapperConnection() returns the DBAL specific connection (OCI8Connection in my use case). That is not a real "native" connection since it is a mere wrapper around the oci8 php module. In particular it doesn't allow to access some specific functions such as:

  • oci_set_action / oci_set_module_name / oci_set_client_info
  • oci_set_prefetch
  • ... other useful functions
    In my case I'm creating a listener that uses the first functions on the list to useful contextual values (eg: symfony controller/action names) to allow fine tuning and monitoring at the dba level. Obviously this is implemented as a cross-cutting concern with a listener without even touching the main application code. So your advise to not using DBAL for such a purpose seems impractical at best.
    Probably a cleaner solution could be to fully encapsulate all the oci8 functions in the OCI8Connection wrapper, creating a real "native" connection. But this is an hard effort, so my approach is more pragmatic.
    I really don't see the whole point of avoiding to "expose the internal connection ressource to avoid possible weird side effects". As a developer I should in any case know what I'm doing and especially when gradually migrating old oci8-based code sharing the same connection is the best approach in my experience. As a side note, improper use of a Connection::getNativeConnection() is just as harmful at least as improper use of EntityManager::getConnection().




[DBAL-1053] quotes in column comment are not escaped for PostreSQL Created: 01/Dec/14  Updated: 02/Dec/14  Resolved: 02/Dec/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: 2.4.3
Fix Version/s: 2.5
Security Level: All

Type: Bug Priority: Minor
Reporter: Johan Desmyter Assignee: Steve Müller
Resolution: Duplicate Votes: 0
Labels: None
Environment:

Debian 7, Symfony 2.3, PostgreSQL 9.1



 Description   

On an entity with a column which as a comment containing a quote, the schema update command doesn't work.

Example entity :

Vendor\Entity\Bob:
type: entity
table: bob
id:
id:
type: integer
generator:

{ strategy: AUTO }

fields:
friend:
type: string
options:
comment: bob's car

The following exception appear :

[Doctrine\DBAL\DBALException]
An exception occurred while executing 'COMMENT ON COLUMN bob.friend IS 'bob's car':
SQLSTATE[42601]: Syntax error: 7 ERREUR: erreur de syntaxe sur ou près de « s car »
LINE 1: ...OLUMN bob.friend IS 'bob's car'

We can see that quot in comment is not escaped.



 Comments   
Comment by Steve Müller [ 02/Dec/14 ]

Already fixed in master branch as of https://github.com/doctrine/dbal/commit/439f67437083cf95c1fa5e56ab1614d7113895fb

See also: https://github.com/doctrine/dbal/pull/657





[DBAL-1052] [GH-731] Update AbstractSchemaManager.php Created: 30/Nov/14  Updated: 02/Dec/14  Resolved: 02/Dec/14

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Invalid Votes: 0
Labels: filter, filtering, schema, schemadiff


 Description   

This issue is created automatically through a Github pull request on behalf of tbelau666:

Url: https://github.com/doctrine/dbal/pull/731

Message:

There is a optional filter included to list only tables/sequences with a specific prefix.



 Comments   
Comment by Doctrine Bot [ 02/Dec/14 ]

A related Github Pull-Request [GH-731] was assigned:
https://github.com/doctrine/dbal/pull/731





[DBAL-1051] [GH-730] Update index name quoting in MySQL table creation Created: 28/Nov/14  Updated: 12/Dec/14  Resolved: 12/Dec/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: None
Fix Version/s: 2.6, 2.5.1
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Reference
is referenced by DBAL-1072 [GH-741] [DBAL-1051] Quote index name... Resolved

 Description   

This issue is created automatically through a Github pull request on behalf of garoevans:

Url: https://github.com/doctrine/dbal/pull/730

Message:

When creating a table that includes an index named with a reserved keyword the index name isn't quoted. When creating the index specifically the name is quote. This bring the table generation SQL inline with the index generation.



 Comments   
Comment by Doctrine Bot [ 29/Nov/14 ]

A related Github Pull-Request [GH-730] was assigned:
https://github.com/doctrine/dbal/pull/730

Comment by Doctrine Bot [ 12/Dec/14 ]

A related Github Pull-Request [GH-730] was closed:
https://github.com/doctrine/dbal/pull/730





[DBAL-1050] [GH-729] Support for database URLs Created: 26/Nov/14  Updated: 05/Dec/14

Status: Open
Project: Doctrine DBAL
Component/s: Drivers
Affects Version/s: None
Fix Version/s: 2.6
Security Level: All

Type: New Feature Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: drivermanager, dsn, uri


 Description   

This issue is created automatically through a Github pull request on behalf of dzuelke:

Url: https://github.com/doctrine/dbal/pull/729

Message:

With a bunch of tests.

Of note:

1. in the case of information present in both URL and "normal" parameters, I'm currently giving priority to the information from the URL; IMO this makes more sense than vice versa (base info would be defined in params, and each developer or environment has a URL that may or may not override that base info, such as charset)
1. the syntax for SQLite is `sqlite:///relativepath.db` or `sqlite://ignoredhost/relativepath.db` for relative, and `sqlite:////tmp/absolutepath.db` or `sqlite://ignoredhost//tmp/absolutepath.db` for absolute paths to the database file (I went back and forth on this, but this way is easier and more consistent; https://github.com/kennethreitz/dj-database-url does the same)
1. extra query params are simply "copied" into `$params` verbatim; makes sense IMO especially considering point number 1



 Comments   
Comment by Doctrine Bot [ 04/Dec/14 ]

A related Github Pull-Request [GH-729] was closed:
https://github.com/doctrine/dbal/pull/729





[DBAL-1049] [GH-728] Ignore pseudo-system objects in table list Created: 25/Nov/14  Updated: 02/Dec/14  Resolved: 02/Dec/14

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

Type: Improvement Priority: Minor
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of healsdata:

Url: https://github.com/doctrine/dbal/pull/728

Message:

These objects are created by turning on replication and they have column types (sysname, xml) that are not supported by Doctrine.

According to Microsoft's support, these are "'pseudo-system' object[s]" that appear in the User Table type instead of the System Table type.

https://social.msdn.microsoft.com/Forums/sqlserver/en-US/135ec547-2214-4da3-bd42-5c458759e144/sysobjectscategory

This issue is very similar to http://www.doctrine-project.org/jira/browse/DBAL-114 so I handled it in the same section of the code as the fix for that issue.



 Comments   
Comment by Doctrine Bot [ 26/Nov/14 ]

A related Github Pull-Request [GH-728] was assigned:
https://github.com/doctrine/dbal/pull/728

Comment by Doctrine Bot [ 02/Dec/14 ]

A related Github Pull-Request [GH-728] was closed:
https://github.com/doctrine/dbal/pull/728

Comment by Steve Müller [ 02/Dec/14 ]

Fixed as of https://github.com/doctrine/dbal/commit/ea3715a100f20741d8a2088896f94c09dfeea920





[DBAL-1048] Function based index Created: 20/Nov/14  Updated: 13/Feb/15

Status: Open
Project: Doctrine DBAL
Component/s: Platforms, Schema Managers
Affects Version/s: 2.4.3, 2.3.5
Fix Version/s: None
Security Level: All

Type: New Feature Priority: Minor
Reporter: Grégoire Paris Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: postgresql


 Description   

I would like to create a function-based index, but it does not seem to be possible ATM. The final goal is to be able to have case insensitive string filters with Postgresql without losing performance.

I tried this mapping :

  indexes:
        my_entity_name_index:
            columns: [ LOWER(name) ]

But here is what doctrine answers :

[Doctrine\DBAL\Schema\SchemaException]

There is no column with name 'LOWER(name)' on table 'my_entity'.



 Comments   
Comment by Marco Pivetta [ 20/Nov/14 ]

I don't think that we can provide platform-specific index column name support here.

Comment by Michael Lambert [ 02/Jan/15 ]

To me this problem is caused by the bigger issue of some DBs defaulting to case-sensitive and some to case-insensitive. From my searching I have been unable to find a solution to make doctrine operate the same across different collations/databases.

Perhaps the issue would be better described as:
Doctrine does not provide consistency between case-sensitive and case insensitive collations/databases

IMHO it would be very beneficial if Doctrine implemented some method for consistency.

I'm not sure if this is the right place to go into more detail, so I'll refrain for now.

Comment by Steve Müller [ 02/Jan/15 ]

Could you please clarify a bit on "From my searching I have been unable to find a solution to make doctrine operate the same across different collations/databases."? What exactly is broken in Doctrine? Can you give examples?

Comment by Michael Lambert [ 02/Jan/15 ]

Nothing is broken, it could just be improved. Having said that, I don't think this would be a minor task.

The issue I am having that lead me to this issue is that like in mysql != like in postgres. Mysql like == postgres ilike.

Additionally, postgres requires a citext for case insensitive text, mysql relies on the db/table collation.

The only way to make a case insensitive unique key in postgres (at least as far as I could find) is to use a function based index.

I hope this helps define the scope of the case sensitivity issues that would be somewhat solved by adding a function based index or a method to enforce case sensitivity /insensitivity.

(sorry for any auto correct failures, I'm on a mobile device on a train)

Comment by Grégoire Paris [ 13/Feb/15 ]

When I create the index manually, without resorting to Doctrine, it does not detect it when updating the schema (might be a bug that was fixed in the latest version IIRC), so I guess this is a workaround in the meantime, but a dangerous one because one can't safely upgrade. Any other ideas ?





[DBAL-1047] doctrine:schema:update ignores index names set on Entity via Annotation Created: 20/Nov/14  Updated: 20/Nov/14  Resolved: 20/Nov/14

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

Type: Bug Priority: Minor
Reporter: webDEVILopers Assignee: Marco Pivetta
Resolution: Duplicate Votes: 0
Labels: schematool
Environment:

"php": ">=5.3.3",
"symfony/symfony": "2.5.*",
"doctrine/orm": "~2.4",
"doctrine/doctrine-bundle": "~1.2"


Issue Links:
Duplicate
duplicates DDC-2989 ORM should allow custom index names f... Resolved

 Description   

I am naming my indexes via annotations in my entity:

/**
 * @ORM\Entity
 * @ORM\Table(name="delivery_notes", indexes={
 *  @ORM\Index(name="location_idx", columns={"location_id"}),
 *  @ORM\Index(name="user_idx", columns={"user_id"}),
 *  @ORM\Index(name="compartment_idx", columns={"compartment_id"})
 * })
 */
class DeliveryNote

When running doctrine:schema:update the names are ignored (at least when they don't exist yet):

CREATE INDEX IDX_1110401E64D218E ON delivery_notes (location_id);
CREATE INDEX IDX_1110401EA76ED395 ON delivery_notes (user_id);
CREATE INDEX IDX_1110401E6136A935 ON delivery_notes (compartment_id);

Is this an expected behaviour?



 Comments   
Comment by Marco Pivetta [ 20/Nov/14 ]

Duplicate of DDC-2989





[DBAL-1046] Broken link Created: 12/Nov/14  Updated: 02/Dec/14

Status: Open
Project: Doctrine DBAL
Component/s: None
Affects Version/s: 2.3.5
Fix Version/s: None

Type: Task Priority: Minor
Reporter: ted bohus Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

On the website, the link to download Doctrine DBAL 2.3.5 doesn't work...

http://www.doctrine-project.org/downloads/DoctrineDBAL-2.3.5-full.tar.gz

Thanks



 Comments   
Comment by Steve Müller [ 02/Dec/14 ]

ted bohus for now please use this link: https://github.com/doctrine/dbal/archive/v2.3.5.zip
We are having a look into the issue.





[DBAL-1045] [GH-727] Disallow empty delete criteria on the connection Created: 11/Nov/14  Updated: 11/Nov/14  Resolved: 11/Nov/14

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: 2.5
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of Ocramius:

Url: https://github.com/doctrine/dbal/pull/727

Message:

See #722

Ping @JeroenDeDauw @asm89



 Comments   
Comment by Doctrine Bot [ 11/Nov/14 ]

A related Github Pull-Request [GH-727] was assigned:
https://github.com/doctrine/dbal/pull/727

Comment by Steve Müller [ 11/Nov/14 ]

Fixed as of https://github.com/doctrine/dbal/commit/e35ce0486a1d161e739bed38fde27b7cc921f5f0





[DBAL-1044] [GH-726] MasterSlaveConnection::close() should reset connections array Created: 10/Nov/14  Updated: 11/Nov/14  Resolved: 11/Nov/14

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: 2.4.3
Fix Version/s: 2.5
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: close, connection, master-slave


 Description   

This issue is created automatically through a Github pull request on behalf of alekitto:

Url: https://github.com/doctrine/dbal/pull/726

Message:

When calling MasterSlaveConnection::close() the connections array should be restored to the default value.
Otherwise a subsequent call to the connect method will fire a PHP Notice because of undefined index in MasterSlaveConnection.php on line 165.



 Comments   
Comment by Doctrine Bot [ 11/Nov/14 ]

A related Github Pull-Request [GH-726] was assigned:
https://github.com/doctrine/dbal/pull/726

Comment by Doctrine Bot [ 11/Nov/14 ]

A related Github Pull-Request [GH-726] was closed:
https://github.com/doctrine/dbal/pull/726





[DBAL-1043] [GH-725] Exclude tables with table_type of VIEW Created: 10/Nov/14  Updated: 24/Nov/14  Resolved: 24/Nov/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms, Schema Managers
Affects Version/s: None
Fix Version/s: 2.5
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of jsor:

Url: https://github.com/doctrine/dbal/pull/725

Message:

This excludes views registered by PostGIS 2.x like geography_columns, geometry_columns, raster_columns and raster_overviews.

The table_name != 'geometry_columns' is kept for PostGIS 1.5 compatibility. The type changed to VIEW in PostGIS 2.0.

Failing tests: https://travis-ci.org/jsor/dbal/builds/40528525 (See #724)



 Comments   
Comment by Doctrine Bot [ 24/Nov/14 ]

A related Github Pull-Request [GH-725] was closed: