[DBAL-1271] MySQL MEDIUMINT is mapped as type INT Created: 27/Jul/15  Updated: 27/Jul/15

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

Type: Bug Priority: Major
Reporter: Scott Connerly Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

In MySqlPlatform in initializeDoctrineTypeMappings(), MEDIUMINT's are treated just the same as INT.

My particular use case is in the context of Laravel, renaming a column that is built as a MEDIUMINT. It gets rebuilt as an INT, and breaks the foreign keys.






[DBAL-1270] [GH-886] Add test for MariaDB 5.5, 10.0 and 10.1 on Travis Created: 23/Jul/15  Updated: 23/Jul/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 PowerKiKi:

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

Message:






[DBAL-1269] Return type of Connection::executeQuery Created: 20/Jul/15  Updated: 20/Jul/15

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

Type: Documentation Priority: Major
Reporter: odan Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Hello

1) The return type of Doctrine\DBAL\Connection::executeQuery
is defined as @return \Doctrine\DBAL\Driver\Statement

But if I make you make a query without $params the return type
is PDOStatement.

// Returns a PDOStatement
$stm = $connetion->executeQuery("SELECT * FROM user;");

2) The member variable $this->_conn is defined as

@var \Doctrine\DBAL\Driver\Connection
protected $_conn;

but it should be \PDO

I'm using v.2.4.4






[DBAL-1268] [GH-885] parameter $database for listTableIndexes, listTableDetails Created: 20/Jul/15  Updated: 20/Jul/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 podbeltsev:

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

Message:






[DBAL-1267] [GH-884] Travis: Switch to container-based infrastructure Created: 16/Jul/15  Updated: 16/Jul/15  Resolved: 16/Jul/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: build-speed, ci, sudo, travis


 Description   

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

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

Message:

Ref: https://github.com/doctrine/doctrine2/pull/1466



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

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





[DBAL-1266] [GH-883] Fixed problem when having subqueries in where clause. Created: 16/Jul/15  Updated: 16/Jul/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

Issue Links:
Duplicate
duplicates DBAL-1265 [GH-882] Fixed problem when having su... Resolved

 Description   

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

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

Message:

Hello,

I had some problems when using a query like
```sql
SELECT a, b, c FROM t1 WHERE (SELECT COUNT FROM t2 WHERE t1.a = t2.a) > 0
```
because the FROM in the WHERE-clause got matched as the "main" FROM. Changing part of the regex to non-greedy seems to fix the problem (without affecting SELECT ... FROM subqueries in the SELECT-part.






[DBAL-1265] [GH-882] Fixed problem when having subqueries in where clause. Created: 16/Jul/15  Updated: 16/Jul/15  Resolved: 16/Jul/15

Status: Resolved
Project: Doctrine DBAL
Component/s: Drivers, Platforms
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: Incomplete Votes: 0
Labels: sqlserver, subquery, where

Issue Links:
Duplicate
is duplicated by DBAL-1266 [GH-883] Fixed problem when having su... Open

 Description   

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

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

Message:

Hello,

I had some problems when using a query like
```sql
SELECT a, b, c FROM t1 WHERE (SELECT COUNT FROM t2 WHERE t1.a = t2.a) > 0
```
because the FROM in the WHERE-clause got matched as the "main" FROM. Changing part of the regex to non-greedy seems to fix the problem (without affecting SELECT ... FROM subqueries in the SELECT-part.



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

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





[DBAL-1264] [GH-881] Add Mysql per-column charset support Created: 15/Jul/15  Updated: 15/Jul/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 mRoca:

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

Message:

Actually with MySQL we can define a collation per column, but the charset seems not supported, whereas specified in the documentation : http://doctrine-dbal.readthedocs.org/en/latest/reference/schema-representation.html#vendor-specific-options

I've added the `CHARACTER SET ***` sql declation for the MySQL platform.

Use case with Doctrine/ORM : `@Column(name="foo", type="text", options=

{"collation"="utf8mb4_unicode_ci", "charset"="utf8mb4"}

)`

Linked PR : #850






[DBAL-1263] [GH-880] drop php 5.3 from travis build matrix Created: 15/Jul/15  Updated: 15/Jul/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/880

Message:



 Comments   
Comment by Doctrine Bot [ 15/Jul/15 ]

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

Comment by Doctrine Bot [ 15/Jul/15 ]

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





[DBAL-1262] [GH-879] workaround for travis composer self-update ipv6 timeout issue Created: 15/Jul/15  Updated: 15/Jul/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/879

Message:

Testing to see if making ipv6 have lower precedence than ipv4 on travis boxes fixes the composer timeout issue.

Workaround from @Seldaek in this issue thread: https://github.com/composer/composer/issues/4142



 Comments   
Comment by Doctrine Bot [ 15/Jul/15 ]

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





[DBAL-1261] return result from Doctrine\DBAL\Connection::transactional Created: 15/Jul/15  Updated: 15/Jul/15  Resolved: 15/Jul/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: Bill Schaller Assignee: Bill Schaller
Resolution: Fixed Votes: 0
Labels: callable, connection, return, transactional, transactions


 Description   

Change Connection::transactional to return the return value of the passed callable.






[DBAL-1260] [GH-878] Fix call on non-object in ping() with PDO wrapper Created: 14/Jul/15  Updated: 15/Jul/15

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

Type: Bug Priority: Minor
Reporter: Doctrine Bot Assignee: Bill Schaller
Resolution: Unresolved Votes: 0
Labels: connection, platform


 Description   

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

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

Message:

Fixes an issue when calling `ping()` where `$this->platform` is null. Happened to me because using the `'pdo'` param bypasses the `connect()` method and the platform is never set without explicitly calling the method.

Not sure if this is the most elegant way to deal with this but it worked enough for my purposes so I figured I should submit a PR.



 Comments   
Comment by Doctrine Bot [ 15/Jul/15 ]

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





[DBAL-1259] QueryBuilder leaves LEFT JOIN out of queries Created: 07/Jul/15  Updated: 07/Jul/15

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

Type: Bug Priority: Major
Reporter: Bill Brower Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: dbal, querybuilder
Environment:

Ubuntu 14.04.2 LTS running
PHP 5.5.22-1+deb.sury.org~precise+1 (cli)
with Zend Engine v2.5.0 and Zend OPcache v7.0.4-dev



 Description   

QueryBuilder throws a non unique alias error for a, seemingly, valid query (as per the documentation and example query on lines 455-458 of the QueryBuilder.php class

$query = $this->queryBuilder
->select("co.*", "cl.client_user_id")
->from("contracts", "co")
->leftJoin("co", "clients", "cl", "co.client_id = cl.id")
->where("co.id = ?")
->setParameter(0, $id)
->execute();

"The given alias 'cl' is not unique in FROM and JOIN clause table. The currently registered aliases are: co, cl."






[DBAL-1258] [GH-876] Remove git submodules Created: 04/Jul/15  Updated: 15/Jul/15  Resolved: 15/Jul/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: Bill Schaller
Resolution: Fixed Votes: 0
Labels: git, git-submodule, repository


 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 15/Jul/15 ]

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





[DBAL-1257] doctrine-dbal will not execute if doctrine/dbal is installed as a dependency Created: 30/Jun/15  Updated: 30/Jun/15

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

Type: Bug Priority: Minor
Reporter: Matthew Turland Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: dbal


 Description   

doctrine-dbal is configured as a vendor binary. However, when doctrine/dbal is installed as a dependency via Composer, while doctrine-dbal is copied to vendor/bin, the doctrine-dbal.php file it requires is not. As such, doctrine-dbal won't work if invoked in this situation.

doctrine-dbal should probably check if doctrine-dbal.php exists in the same directory and, if not, instead include it from __DIR__ . '/../doctrine/dbal/bin/doctrine-dbal.php'.



 Comments   
Comment by Christophe Coevoet [ 30/Jun/15 ]

Composer will never copy bin files, as this would indeed always break any requirement in them (which would involve copying the whole library too). It either creates symlinks or create proxy files calling the original one, depending on your system. In both cases, the doctrine file stays in its place, and so everything works fine.

I also see 2 reasons which could break things:

  • if you have a tool replacing the files generated by Composer by their own files and doing it in a crappy way => solution: stop using this tool until they fix their mess
  • if you have a broken setup advocating it can create symlinks but then actually copying files (I think this may happen in some cases with VMs when you are in shared folders, but I'm not sure) => solution: fix your system.

In any case, there is nothing which should be changed in Doctrine DBAL IMO, as DBAL works totally fine for the expected Composer behavior.
Thus, your proposal would not work for people moving their composer bin-dir to a custom location, so it is not even an acceptable workaround.





[DBAL-1256] SqliteSchemaManager do not found type of tableColumn if contain whitespace Created: 28/Jun/15  Updated: 28/Jun/15

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

Type: Bug Priority: Major
Reporter: Hermann Bernwald Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: dbal, schemamanager, sqlite

Attachments: Text File output.txt     Text File SqliteSchemaManager.patch    

 Description   

source:
https://www.fuzzwork.co.uk/dump/sqlite-latest.sqlite.bz2

input:
CREATE TABLE certSkills (certID integer DEFAULT NULL, skillID integer DEFAULT NULL, certLevelInt integer DEFAULT NULL, skillLevel integer DEFAULT NULL, certLevelText VARCHAR (8) DEFAULT NULL, CONSTRAINT id PRIMARY KEY (certID, skillID, certLevelInt, skillLevel, certLevelText));

command:
doctrine:mapping:import

output:
Unknown database type varchar requested, Doctrine\DBAL\Platforms\SqlitePlatform may not support it

solution:
add trim() to $tableColumn['type'] = $parts[0]; in SqliteSchemaManager line 248






[DBAL-1255] [GH-875] Generating a ColumnDiff led to unquoted Columns for Postgres Created: 28/Jun/15  Updated: 28/Jun/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 tk-s:

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

Message:

Postgres needs (or understands) quoted column-names all the Time, especially if one is using mix cased column names.
While generating Diffs, the old column name got no quotation.






[DBAL-1254] FIX TINYINT(1) - Make BOOL use BIT Created: 27/Jun/15  Updated: 28/Jun/15

Status: Open
Project: Doctrine DBAL
Component/s: None
Affects Version/s: 2.2, 2.2.1, 2.2.2, 2.3, 2.3.1, 2.3.2, 2.3.3, 2.4, 2.3.4, 2.5, 2.4.1, 2.4.2, 2.4.3, 2.3.5, 2.4.4, 2.5.1
Fix Version/s: 3.0
Security Level: All

Type: Improvement Priority: Minor
Reporter: Jonathan Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

All environments


Issue Links:
Reference
relates to DBAL-781 Doctrine maps tinyint with length > 1... Resolved

 Description   

1. MySQL doesnt have boolean type but it supports BIT(1) which in my more novice opinion would be more effective if you wanted to use something to map. OR just not made a boolean type. Ideally, a programmer would go I am using the MySQL database engine, no boolean, let me use a TINY INT. So instead of making the programmer think you dumbed down a field that can store 255unsigned valyes into one that stores TRUE OR FALSE.

2. Now I need to use 2 bytes of data to store the integer 2-255unsigned in smallint. So think about all of the fields that could use TINYINT to store configurations or settings where there is more than a true false. Account types, account status, day of week, day of month, current AGE, date at death, age required to do XYZ, You do not offer enum and you made a strong tiny integer into a weak bipolar newborn.

3. By requiring two bites of data to these fields you will be double the data storage in probably 1 out of 5 of my columns. If you had a million records with this issue that is an extra 1MB of unneeded database size. This may slow performance of select and other MySQL operation fractionally.

4. In summary, you spoon fed developers a weak FAT bipolar newborn. Give us back out functionality, allow us to trim down and NORMALIZE properly, stop cross-mapping data types. You take away all enum options. This is ONE major major major major benefit of Propel is that they at least have TINYINT. Also: built in behaviors versus complaining that its too hard to test and maintain behaviors. I respect Doctrine and chose it for its stability and strength. Everyone makes mistakes but please fix this one. Sorry in advance for being rude but I preferred being honest versus being a suck-up.

Love your application, thank you very much for being SRP friendly(data mapper) stable 2.x, part of symphony install by default/massive tutorial/knowledge base online, more contributors, active contributors, ROADMAP(they refuse to use one in PROPEL), easier to unit test. I spent weeks reading every word about both. Thank you for listening.

I decided to post this as an issue and left the comment on (http://www.doctrine-project.org/jira/browse/DBAL-781) so others searching for this issue would realize other people have this frustration and it is not just them. Also everyone was searching online for a list of comparable to Propel benefits so I added that in for a little SEO love.



 Comments   
Comment by Marco Pivetta [ 27/Jun/15 ]

By requiring two bites of data to these fields you will be double the data storage in probably 1 out of 5 of my columns. If you had a million records with this issue that is an extra 1MB of unneeded database size. This may slow performance of select and other MySQL operation fractionally.

I'd rather say that it is very unlikely to use the ORM in a context where 2 bytes per record makes such a huge difference.

I generally agree with the enhancement proposal (which cannot be implemented in 2.x), but I disagree with the fact that using a small integer is a problem there (we chose it for portability first).

As for ENUM s, it is a bad idea to have them anyway: http://stackoverflow.com/questions/8750724/what-do-you-use-instead-of-enum-in-doctrine2/9057352#9057352

That said, moving to BIT is a good idea for 3.x, which I'll add to the resolution versions.

Comment by Jonathan [ 27/Jun/15 ]

Thank you for setting in motion a change to give me the power of TinyINT back.

It is not 2bytes per record, it is 2 bytes PER column PER record. There is some tables where I may have 3 or 4 or almost all of the columns in (settings tables) that are all TinyINT. Just a concern for performance as that was one of the comments mentioned about a Doctrine weakness.

Ideally you would just map incoming booleans to a char(1) and not run into the same problem we have here with bit since bit supports long bit strings as well as short. However, that is more edge case than TinyINT at least for me. There would be no outgoing boolean and map TinyINT outgoing to whatever would be good for the accepting new database type.

Again, anything to give me a Doctrine TinyINT. Also, please consider behaviors. Thank you.

Comment by Marco Pivetta [ 27/Jun/15 ]

It is not 2bytes per record, it is 2 bytes PER column PER record. There is some tables where I may have 3 or 4 or almost all of the columns in (settings tables) that are all TinyINT. Just a concern for performance as that was one of the comments mentioned about a Doctrine weakness.

I still don't see the massive overhead that you are seeing here
The ORM would still be more overhead than all of this composed.

Comment by Jonathan [ 28/Jun/15 ]

1. Stop comparing ORM to DB performance. Each layer should be optimized separately. Unfortunately you have removed this performance encapsulation ability with only supporting half of MYSQL types. Everyone that tauts doctrine versus Propel, and including even in your own documentation it talks about best practices, and about highly optimized systems, SOLIDoop, SRP, etc, etc. However you think it is okay to DOUBLE the storage requirements of a column for no reason. Heres an analogy: Thats like paying for two parking spots for your car when you only need 1. Also since you read into memory every byte when doing any table lookup or disk reads then you are not just double storage, you are doubling EXPENSIVE memory and processor loads due to buffer size.

2. Also, if the ORM is a slow pig. I need my database to be a fast horse. EVERY single optimization tutorial says use the SMALLEST datatype possible for your requirements.

3. MySQL has a bool/boolean name alias for TinyINT (Just read more on this because I want the best solution in future and I am willing to help with research and suggestions to keep an amazing project stay amazing.) You can use this in your mapping set so when you have incomming boolean mappings they get converted to MySQL. If they are converting away from MySQL to something like Oracle or Postgre they will have bigger things to worry about then converting TinyINT types to booleans and in this case. The problem is an incompatability outside your control. This allows the use of boolean incoming imports that map to TinyINT as you have before and it is Native. Also you can still many TinyINT directly. This prevents the cross-mapping anything. Also it leaves the design in the hands of the database designer. Remember encapsulate responsibilities.

4. Your arguement ONLY makes sense for NDBcluster storage engine as all NDB data storage is done in multiples of 4 bytes so TinyINT,SmallINT,MediumINT,INT are all the same storage.

5. However, when I have to double so far 1 in 7 colums size and I am not using NDB. I become concerned about performance from the database besides the performance encapsulation issue.

6. Using one problem to answer another is not beneficial. It is analogous to answering a question with another question.

7. Thank you in advance for your replies, your open willingness to listen and your active integration of my suggestions into doctrines future. It is a major confidence builder in the project.

Comment by Jonathan [ 28/Jun/15 ]

8. please do not take offense at all, this is not a personal attack on you at all. This is me, as a novice developer/dba trying to say that the lack of 1 to 1 data type matching in a layer that is supposed to provide a fluid interface results in performance loss.

Thank you for taking the time to read and respond to my reasoning behind my request to be 1st class data mapper for MySQL. I understand the difficulties in trying to be an abstraction layer and convert between all data base engines.
It is just so insane to have to store all of my TinyINT in SmallINT columns just to avoid being confused for a boolean when you run "orm:schema-tool:create" and/or "orm:generate-entities".





[DBAL-1253] Sqlite: inconsistent (non-)support of foreign keys Created: 26/Jun/15  Updated: 26/Jun/15

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: Adirelle Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Tested on Ubuntu 14.10 wth standard PHP packages (5.6 & sqlite 3.8.6) and on Debian Jessie with standard PHP packages (5.6 & sqlite 3.8.6).



 Description   

Though the SqlitePlatform announces it doesn't support foreign keys, it generates foreign key constraints in "alter table" statements.

This leads to issues when combined with Doctrine ORM and/or Doctrine Migrations : the shcema manager doesn't create foreign keys on new tables, but it generates SQL statement to add them on existing tables.

  • Calling the schema update command several times in a row on an existing database causes all tables with relations to be recreated (since Sqlite ALTER TABLE statement is very limited).
  • Even if the database is up to date, using the "diff" command of Doctrine Migrations creates a migration the recreate all tables.

I suggest to disable the declaration of foreign keys at all to avoid these discrepancies.

Background:

  • Before Sqlite 3.6.19, declarations of foreign keys in CREATE TABLE were accepted (and retrieved) but ignored.
  • Starting with 3.6.19, there is a compile option to disable the support of the foreign key syntax in CREATE TABLE statement. There is another compile option to disable the triggers, including foreign key ones. These options can be queried using a PRAGMA statement.
  • Starting with 3.6.19, there is a PRAGMA to enforce the respect of foreign keys.
  • in any case, foreign keys are not supported in ALTER TABLE statements.





[DBAL-1252] [GH-874] convertToDatabaseValueSQL with $columnName Created: 21/Jun/15  Updated: 24/Jun/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 mihai-stancu:

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

Message:

Goal:

I want to be able to atomically increment a property such that $stock->setQuantityDelta(2); will render into an SQL such as UPDATE stock SET quantity = quantity+? WHERE id = ?;.

I would like to accomplish this without using DQL every time it is necessary hence I implemented a custom Doctrine2 type which can accomplish this – with support from this PR.

Changes:

Added a new $columnName parameter to \Doctrine\DBAL\Types\Type::convertToDatabaseValueSQL which would be passed by \Doctrine\ORM\Persisters\BasicEntityPersister::updateTable (PR) and used by the concrete type instance (ex.: mihai-stancu/doctrine-types-extra:\MS\Doctrine\DBAL\Types\DeltaType).



 Comments   
Comment by Doctrine Bot [ 22/Jun/15 ]

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

Comment by Doctrine Bot [ 24/Jun/15 ]

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





[DBAL-1251] [GH-873] use travis_retry to avoid network timeout with composer Created: 21/Jun/15  Updated: 15/Jul/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 mathroc:

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

Message:

let's see if it actually works



 Comments   
Comment by Doctrine Bot [ 15/Jul/15 ]

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





[DBAL-1250] [GH-871] SqlConsoleCommand: Showing results of queries containing RETURNING Created: 18/Jun/15  Updated: 18/Jun/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 bountin:

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

Message:

PostgreSQL supports returning values after they are inserted or updated which is especially handy if one wants to get the value of an used sequence. (See http://www.postgresql.org/docs/9.4/static/sql-insert.html) Those returned values are currently omitted but could be displayed.

Currently (with symfony):
```
vagrant@packer-parallels-iso:/vagrant��� app/console doctrine:query:sql "INSERT INTO account (id) VALUES (uuid_generate_v4()) RETURNING id"
int 0
```
After the patch the output is the following:
```
array (size=1)
0 =>
array (size=1)
'id' => string 'ad7a7c8f-72fd-48b9-b216-568ac204649d' (length=36)
```

Looking directly for 'returning' is a bit direct in my eyes but as there is no sql parser present, there is no other easy way to do so. If someone has a better implementation or any suggestion, feel free to comment






[DBAL-1249] [GH-869] Make date and time types throw exception when invalid values are passed to convertToDatabaseValue Created: 17/Jun/15  Updated: 17/Jun/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/869

Message:






[DBAL-1248] WindowsServer / SQLServer modifyLimitQuery does not work with aggregate functions in ORDER BY Created: 16/Jun/15  Updated: 16/Jun/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: Luca Cerretani Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: dbal, sqlserver
Environment:

Windows Server 2008 / SQL Server 2008



 Description   

The `modifyLimitQuery` method does not work with query on multiple lines in Windows Server.
See the example below:

$sql = "SELECT
	table_one.id,
	table_one.number,
	table_two.name
	FROM table_one
	LEFT JOIN table_two
	ON table_two.table_one_id = table_one.id
	ORDER BY table_one.id DESC
";

$sql = $this->em->getConnection()->getDatabasePlatform()->modifyLimitQuery($sql, 1, 0);

Doctrine generates this SQL which is invalid

SELECT * FROM (SELECT table_one.id, table_one.number, table_two.name FROM table_one LEFT JOIN table_two ON table_two.table_one_id = table_one.id) AS doctrine_tbl WHERE doctrine_rownum BETWEEN 1 AND 1 ORDER BY doctrine_rownum

It should be

SELECT * FROM (SELECT table_one.id, table_one.number, table_two.name, ROW_NUMBER() OVER (ORDER BY table_one.id DESC) AS doctrine_rownum  FROM table_one LEFT JOIN table_two ON table_two.table_one_id = table_one.id) AS doctrine_tbl WHERE doctrine_rownum BETWEEN 1 AND 1 ORDER BY doctrine_rownum

If I change the

$selectFromPattern = '/^(\s*SELECT\s+(?:(.*)(?![^(]*\))))\sFROM\s/i';

and use instead

$selectFromPattern = '\sFROM\s/i';

The preg_replace works fine but i get another error in the order by clause.
The doModifyLimitQuery trim out the table name and I get the error "column name id is ambiguous". The uncorrect generated sql is

SELECT * FROM (SELECT table_one.id, table_one.number, table_two.name, ROW_NUMBER() OVER (ORDER BY id DESC) AS doctrine_rownum  FROM table_one LEFT JOIN table_two ON table_two.table_one_id = table_one.id) AS doctrine_tbl WHERE doctrine_rownum BETWEEN 1 AND 1 ORDER BY doctrine_rownum





[DBAL-1247] [GH-868] Make SQLite honor the "memory" option for in-memory db Created: 14/Jun/15  Updated: 14/Jun/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 mikeSimonson:

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

Message:

Shouldn't this be the default behavior ?



 Comments   
Comment by mikeSimonson [ 14/Jun/15 ]

Especially regarding the documentation http://doctrine-dbal.readthedocs.org/en/latest/reference/configuration.html#pdo-sqlite





[DBAL-1246] [GH-867] Fix fk schemadiff renamed column Created: 12/Jun/15  Updated: 12/Jun/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/867

Message:

In situations where SQL is generated with SchemaDiff::toSaveSql, foreign keys for columns that have been renamed or removed were not being dropped if the referenced table was orphaned.






[DBAL-1245] Unexpected behavior when getting schema updates from ORM Created: 12/Jun/15  Updated: 18/Jun/15

Status: Awaiting Feedback
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: Tony Georges Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: dbal, oracle, orm, schematool
Environment:

OSX PHP5.3.3 SF2.7 ORACLE



 Description   

Hi all, I found a problem using DBAL and schema update :

My setup :

DBAL 2.5.1, Oracle OCI

I ask for schema updates using command
>php app/console doctrine:schema:update --dump-sql

Result :

ALTER INDEX idx_ab074de1ef5927f RENAME TO IDX_FFF42BF5727ACA70;
ALTER INDEX idx_218e7204ef5927f RENAME TO IDX_6E75D7727ACA70;
ALTER INDEX idx_85c03c85ee8c0707 RENAME TO IDX_1AB76DA1B52C0544;
ALTER INDEX idx_523305bac5653160 RENAME TO IDX_D6AFDC364E833AFF;
ALTER INDEX idx_523305babb38df8d RENAME TO IDX_D6AFDC36ED1C4E5;
ALTER INDEX idx_523305baee8c0707 RENAME TO IDX_D6AFDC36B52C0544;
ALTER INDEX idx_ddcece30d8abdcf4 RENAME TO IDX_22ABD2A38661593;
ALTER INDEX idx_6743b99ac5653160 RENAME TO IDX_5C4ACA974E833AFF;
ALTER INDEX idx_6743b99a691f1cfc RENAME TO IDX_5C4ACA974C5B503A;
ALTER INDEX idx_fc1af60cf41679cd RENAME TO IDX_FC1AF60C15A17E77;
ALTER INDEX idx_4c268f82f41679cd RENAME TO IDX_4C268F82C7C42212;
ALTER INDEX idx_4c268f82a6e00f45 RENAME TO IDX_4C268F82DA6F574A;
ALTER INDEX idx_7ca8bc6df41679cd RENAME TO IDX_7CA8BC6D15A17E77;
...

After investigating, Doctrine\ORM\Tools\SchemaTool asks the "from" Schema to OracleSchemaManager and the "to" schema is build from metadata information.
The from schema list each tables and their content : columns, indexex and constraints from Oracle Database. ListTables result is well formed.

After that, SchemaManager build a Doctrine\DBAL\Schema\Table object (in listTableDetails) to represent each table.
Table construct index associated to constraint (internally considered as implicit index).

This index is then interpreted as an existing database index by Comparator :
it generates a SchemaDiff object that contains SQL statements "Rename" or "Drop/Create" (depends of DBAL versions) on these implicit indexes that does not exist in database.

To sum up

  • SchemaTool ask schema "from" to SchemaManager
  • SchemaManager read schema from database (OK)
  • Table generate non existing implicit index (OK)
  • Comparator generate diff and consider these indexes as existing (NOK)

Today I fix it by appending a contructor argument to Table in order to not generate implicit indexes.
I think this can also be fixed by opening the concept of implicit index to public namespace and implement its usage in Comparator and other tools because this information can be very usefull in other ORM tools.

Do you think there is another approach for my problem ?

Thanks for reading,

Tony






[DBAL-1244] Large update with JSON results in segfault Created: 10/Jun/15  Updated: 10/Jun/15

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

Type: Bug Priority: Major
Reporter: Damjan Znidarsic Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None

Attachments: File test.php    

 Description   

There's a really heavy regex in:
\Doctrine\DBAL\SQLParserUtils::getPlaceholderPositions

that is evaluated on every update. The longer the json string is, the more backtracks the regex does, resulting in a segfault related to pcre and this bug:
https://bugs.php.net/bug.php?id=45735

Attached is a test.php to reproduce this. Can the regex be simplified or this implemented in some other way ?






[DBAL-1243] Unique Key on two columns overrules three column index causing drop index Created: 09/Jun/15  Updated: 09/Jun/15

Status: Open
Project: Doctrine DBAL
Component/s: Schema Managers
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Trivial
Reporter: Arkadiusz Rzadkowolski Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Running schema compare will result with index being returned for removal.

DROP INDEX OPB_BLG_IDX1 ON OPB_BLOGS;

The reason for that is that OPB_BLG_IDX1 matches two columns (BLG_DOMAIN, BLG_PATH) with unique key OPB_BLG_UK1. It skips check for last column (BLG_STATUS).

Shouldn't spansColumns method be run on same type of index only? Right now OPB_BLG_IDX1 is being removed since doctrine thinks it's overruled by unique key (and I don't think it should be treated that way).

Example annotation (problem is with OPB_BLG_UK1 & OPB_BLG_IDX1 as stated above):

/**
 * OpbBlogs
 *
 * @ORM\Table(name="OPB_BLOGS", uniqueConstraints={@ORM\UniqueConstraint(name="OPB_BLG_UK1", columns={"BLG_DOMAIN", "BLG_PATH"})},
 * indexes={
 *      @ORM\Index(name="OPB_BLG_IDX1", columns={"BLG_DOMAIN", "BLG_PATH", "BLG_STATUS"}),
 *      @ORM\Index(name="OPB_BLG_IDX2", columns={"BLG_USR_ID"}),
 *      @ORM\Index(name="OPB_BLG_IDX3", columns={"BLG_TYP_ID"}),
 *      @ORM\Index(name="OPB_BLG_IDX4", columns={"BLG_CAT_ID"}),
 *      @ORM\Index(name="OPB_BLG_IDX5", columns={"BLG_DOMAIN"}),
 *      @ORM\Index(name="BLG_CREATED_DATE", columns={"BLG_CREATED_DATE"}),
 *      @ORM\Index(name="BLG_ID", columns={"BLG_ID", "BLG_LAST_POST_ID"}),
 *      @ORM\Index(name="BLG_LAST_POST_DATE", columns={"BLG_LAST_POST_DATE"}),
 *      @ORM\Index(name="BLG_SLT_ID", columns={"BLG_SLT_ID", "BLG_DBNAME"})
 * })
 *
*@ORM\Entity
 */





[DBAL-1242] [GH-866] Fix issue with zero date for DateTime Type Created: 07/Jun/15  Updated: 08/Jun/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 Fedik:

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

Message:

Fix PHP issue with zero date for DateTime Type,
when PHP return `-0001-11-30 00:00:00` for `0000-00-00 00:00:00` value



 Comments   
Comment by Doctrine Bot [ 08/Jun/15 ]

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





[DBAL-1241] Comparator generates wrong result if using database_name.table_name notation Created: 28/May/15  Updated: 28/May/15

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

Type: Bug Priority: Major
Reporter: Pavlo Chipak Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: dbal, mysql, schematool
Environment:

Mysql 5.6.21, PHP 5.6.3, Windows



 Description   

At fist created issue in migrations https://github.com/doctrine/migrations/issues/258 but was referenced here.

I'm using Symfony2. In entities schemas configs I'm using dot notation in table names (database_name.table_name) for cross-database joins. When I create migration, there are no deletes of created foreign keys in down() method. Example (some unnecessary code removed):

    public function up(Schema $schema)
    {
        $this->addSql('CREATE TABLE import.article (id INT AUTO_INCREMENT NOT NULL, edition_id INT DEFAULT NULL, title VARCHAR(255) NOT NULL, subtitle LONGTEXT NOT NULL, theme VARCHAR(255) NOT NULL, bar VARCHAR(255) NOT NULL, text LONGTEXT NOT NULL, createdAt DATETIME NOT NULL, editedAt DATETIME DEFAULT NULL, creator_id INT DEFAULT NULL, editor_id INT DEFAULT NULL, INDEX IDX_71D0368461220EA6 (creator_id), INDEX IDX_71D036846995AC4C (editor_id), INDEX IDX_71D0368474281A5E (edition_id), PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB');
        $this->addSql('CREATE TABLE import.author (id INT AUTO_INCREMENT NOT NULL, article_id INT DEFAULT NULL, name VARCHAR(255) NOT NULL, createdAt DATETIME NOT NULL, editedAt DATETIME DEFAULT NULL, creator_id INT DEFAULT NULL, editor_id INT DEFAULT NULL, INDEX IDX_8B81B94F61220EA6 (creator_id), INDEX IDX_8B81B94F6995AC4C (editor_id), INDEX IDX_8B81B94F7294869C (article_id), PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB');
        $this->addSql('CREATE TABLE import.document (id INT AUTO_INCREMENT NOT NULL, edition_id INT DEFAULT NULL, title LONGTEXT NOT NULL, number VARCHAR(255) NOT NULL, theme VARCHAR(255) NOT NULL, department VARCHAR(255) NOT NULL, adoptedAt DATETIME NOT NULL, type INT NOT NULL, text LONGTEXT NOT NULL, createdAt DATETIME NOT NULL, editedAt DATETIME DEFAULT NULL, creator_id INT DEFAULT NULL, editor_id INT DEFAULT NULL, INDEX IDX_961EE31A61220EA6 (creator_id), INDEX IDX_961EE31A6995AC4C (editor_id), INDEX IDX_961EE31A74281A5E (edition_id), PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB');
        $this->addSql('CREATE TABLE import.edition (id INT AUTO_INCREMENT NOT NULL, periodical_id INT DEFAULT NULL, publication_id INT DEFAULT NULL, region_id INT DEFAULT NULL, issue INT NOT NULL, number INT NOT NULL, publishedAt DATETIME NOT NULL, createdAt DATETIME NOT NULL, editedAt DATETIME DEFAULT NULL, creator_id INT DEFAULT NULL, editor_id INT DEFAULT NULL, INDEX IDX_DB7B20FD61220EA6 (creator_id), INDEX IDX_DB7B20FD6995AC4C (editor_id), INDEX IDX_DB7B20FD855A7B04 (periodical_id), INDEX IDX_DB7B20FD38B217A7 (publication_id), INDEX IDX_DB7B20FD98260155 (region_id), PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB');
        $this->addSql('CREATE TABLE import.image (id INT AUTO_INCREMENT NOT NULL, storage_id INT NOT NULL, width VARCHAR(255) NOT NULL, height VARCHAR(255) NOT NULL, material INT NOT NULL, material_type VARCHAR(50) NOT NULL, creator_id INT DEFAULT NULL, editor_id INT DEFAULT NULL, INDEX IDX_E81675F561220EA6 (creator_id), INDEX IDX_E81675F56995AC4C (editor_id), PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB');
        $this->addSql('CREATE TABLE import.periodical (id INT AUTO_INCREMENT NOT NULL, name VARCHAR(255) NOT NULL, alias VARCHAR(255) NOT NULL, createdAt DATETIME NOT NULL, editedAt DATETIME DEFAULT NULL, creator_id INT DEFAULT NULL, editor_id INT DEFAULT NULL, INDEX IDX_AF07D39961220EA6 (creator_id), INDEX IDX_AF07D3996995AC4C (editor_id), PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB');
        $this->addSql('CREATE TABLE import.publication (id INT AUTO_INCREMENT NOT NULL, name VARCHAR(255) NOT NULL, createdAt DATETIME NOT NULL, editedAt DATETIME DEFAULT NULL, creator_id INT DEFAULT NULL, editor_id INT DEFAULT NULL, INDEX IDX_94AF610261220EA6 (creator_id), INDEX IDX_94AF61026995AC4C (editor_id), PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB');
        $this->addSql('CREATE TABLE import.region (id INT AUTO_INCREMENT NOT NULL, name VARCHAR(255) NOT NULL, createdAt DATETIME NOT NULL, editedAt DATETIME DEFAULT NULL, creator_id INT DEFAULT NULL, editor_id INT DEFAULT NULL, INDEX IDX_394C90F161220EA6 (creator_id), INDEX IDX_394C90F16995AC4C (editor_id), PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB');
        $this->addSql('ALTER TABLE import.article ADD CONSTRAINT FK_71D0368474281A5E FOREIGN KEY (edition_id) REFERENCES import.edition (id)');
        $this->addSql('ALTER TABLE import.author ADD CONSTRAINT FK_8B81B94F7294869C FOREIGN KEY (article_id) REFERENCES import.article (id)');
        $this->addSql('ALTER TABLE import.document ADD CONSTRAINT FK_961EE31A74281A5E FOREIGN KEY (edition_id) REFERENCES import.edition (id)');
        $this->addSql('ALTER TABLE import.edition ADD CONSTRAINT FK_DB7B20FD855A7B04 FOREIGN KEY (periodical_id) REFERENCES import.periodical (id)');
        $this->addSql('ALTER TABLE import.edition ADD CONSTRAINT FK_DB7B20FD38B217A7 FOREIGN KEY (publication_id) REFERENCES import.publication (id)');
        $this->addSql('ALTER TABLE import.edition ADD CONSTRAINT FK_DB7B20FD98260155 FOREIGN KEY (region_id) REFERENCES import.region (id)');
    }

    public function down(Schema $schema)
    {
        $this->addSql('DROP TABLE import.article');
        $this->addSql('DROP TABLE import.author');
        $this->addSql('DROP TABLE import.document');
        $this->addSql('DROP TABLE import.edition');
        $this->addSql('DROP TABLE import.image');
        $this->addSql('DROP TABLE import.periodical');
        $this->addSql('DROP TABLE import.publication');
        $this->addSql('DROP TABLE import.region');
    }

This is lost

        $this->addSql('ALTER TABLE import.article DROP FOREIGN KEY FK_71D0368474281A5E');
	$this->addSql('ALTER TABLE import.author DROP FOREIGN KEY FK_8B81B94F7294869C');
        $this->addSql('ALTER TABLE import.document DROP FOREIGN KEY FK_961EE31A74281A5E');
        $this->addSql('ALTER TABLE import.edition DROP FOREIGN KEY FK_DB7B20FD855A7B04');
        $this->addSql('ALTER TABLE import.edition DROP FOREIGN KEY FK_DB7B20FD38B217A7');
        $this->addSql('ALTER TABLE import.edition DROP FOREIGN KEY FK_DB7B20FD98260155');

I had make some research and concluded that in class Doctrine\DBAL\Schema\Comparator in line 91 (https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Schema/Comparator.php#L91) replacing getShortestName by getName fixes this problem. But I'm sure it's not complete fix of this problem.



 Comments   
Comment by mikeSimonson [ 28/May/15 ]

As I explained to you, your problem only exist because of the order of those delete statement.

Maybe the delete statement could be ordered taking into account the tree of dependencies created by the foreign keys ?





[DBAL-1240] [GH-864] Fix undefined notices within MasterSlaveConnection Created: 22/May/15  Updated: 22/May/15  Resolved: 22/May/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

To fix the following notice-level errors:

Notice: Undefined property: Doctrine\DBAL\Connections\MasterSlaveConnection::$_conn in vendor/doctrine/dbal/lib/Doctrine/DBAL/Connections/MasterSlaveConnection.php line 154
Notice: Undefined index: slave in vendor/doctrine/dbal/lib/Doctrine/DBAL/Connections/MasterSlaveConnection.php line 165



 Comments   
Comment by Doctrine Bot [ 22/May/15 ]

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

Comment by Guilherme Blanco [ 22/May/15 ]

Merged





[DBAL-1239] Comparator::compare() erroneously includes schema creation Created: 22/May/15  Updated: 22/May/15

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

Type: Bug Priority: Major
Reporter: Alan Egerton Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

DoctrineMigrations, PostgreSQL v9.4



 Description   

I reported the issue below to the Migrations project, but was told that the problem stems from DBAL's comparison of schema objects—

Whenever I use :diff against a PostgreSQL backend, the generated down migrations always start with CREATE SCHEMA.

This not only causes down migrations to fail (because the schema already exists and hence that command raises an error), but also results in :diff generating migrations even where no differences exist (they contain that command alone).






[DBAL-1238] [GH-863] Strip leading slash of databasename from URL Created: 21/May/15  Updated: 21/May/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

Issue Links:
Duplicate
is duplicated by DBAL-1234 Additional slash in dbname when provi... Open

 Description   

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

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

Message:

This is actuall the commit for DBAL-1234(http://www.doctrine-project.org/jira/browse/DBAL-1234)

When using a custom driver via `driverClass` in all (some?) cases one cannot set
the scheme properly. In the earlier implementation when the scheme is missing the
`DriverManager` leaves the leading slash in the path, because it silently assumes,
that this is a SQLite-connection. With custom drivers this leads to invalid database
names.

Additionally this takes care, that if one specifies the driver via configuration key
`driver`, but the connection with scheme-less URL it ends up in an invalid database
name too������

driver: pdo_mysql
������ url: //user:pass@localhost/database

Another solution is to introduce a special `custom`-scheme, that doesn't point to a driver, but declares, that `driverClass` is required

custom://foo:bar@localhost:123/my_db

However, this would not take care of the other use-case,






[DBAL-1237] [GH-862] Pass table object instead of table table name Created: 21/May/15  Updated: 21/May/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 mpoiriert:

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

Message:

On the MySQLPlatform::getDropForeignKeySQL table name will not be escaped if the name is passed instead of the object table itself.

Since the getLocalTableName use the localTable property the object is always available, there is no reason not to use it.






[DBAL-1236] [GH-861] Check for foreign table name on removed tables foreign key Created: 21/May/15  Updated: 21/May/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 mpoiriert:

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

Message:

According to the comment

// deleting duplicated foreign keys present on both on the orphanedForeignKey
// and the removedForeignKeys from changedTables

A check must be had on the $removedForeignKey so it does point on the removed table. Currently it does unset all keys removal even the one pointing on other table.

This should probably be added to a previous version since it's a bug fix but I don't know the exact flow you are following for this.






[DBAL-1235] [GH-857] Update DateTimeType.php Created: 21/May/15  Updated: 21/May/15  Resolved: 21/May/15

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
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: datetime, type, type-conversion, type-safety, types


 Description   

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

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

Message:



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

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

Comment by Doctrine Bot [ 21/May/15 ]

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





[DBAL-1234] Additional slash in dbname when providing settings as URL without scheme Created: 21/May/15  Updated: 21/May/15

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

Type: Bug Priority: Minor
Reporter: Sebastian Krebs Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None

Issue Links:
Duplicate
duplicates DBAL-1238 [GH-863] Strip leading slash of datab... Open

 Description   

Hi,

I use https://github.com/realestateconz/MssqlBundle to connect to an MSSQL-database and I'd like to provide the connection parameters as URL. Because dblib is not a supported driver I setup the driverClass instead

driver_class:   \Realestate\MssqlBundle\Driver\PDODblib\Driver

So the corresponding URL would look like

//user:pass@127.0.0.1/dabasename

But now it tries to connect to the database /databasename instead of databasename. I can set an arbitrary scheme here as long as it exists and is supported (and is not SQLite)

mysqli://user:pass@127.0.0.1/dabasename

Now it works, but it's a hack.

It seems, that the issue is here
https://github.com/doctrine/dbal/blob/32b1a4f85a078f67752851c27be4065071db1f8b/lib/Doctrine/DBAL/DriverManager.php#L262
As long as there is no scheme the leading slash remains. I'd guess, that it should also take into account, that there might be no driver name, but a concrete driverClass instead

(!isset($url['scheme']) && !isset(isset($url['driverClass']))

?






[DBAL-1233] TEXT type in MSSQL should be NVARCHAR(MAX) not VARCHAR(MAX) Created: 19/May/15  Updated: 26/Jun/15  Resolved: 26/Jun/15

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

Type: Bug Priority: Major
Reporter: Javad Rahimi Assignee: Benjamin Eberlei
Resolution: Incomplete Votes: 0
Labels: mssql, nvarchar(max), schema, text, validator


 Description   

If a field type is defined as "TEXT" by generating the schema in MSSQL Server it generates a field type as "VARCHAR(MAX)". There will be no problem unless some UTF8 characters be inserted to DB; they all will be saved as "?????". If the field type be changed to "NVARCHAR(MAX)" there will be no problem and UTF8 characters will saved properly.
In this case I changed the DBAL core for SQL server as:

DoctrineDBALplatformsSQLServer2005Platform.php
public function getClobTypeDeclartionSQL(array $field)
{
     return 'NVARCHAR(MAX)';
}

This fixed the main issue but after I generate the schema, whenever I validate my schema, it returns false on DB level.
Could anybody help me in this case? Is there any other fixes I need to do?

Appreciate it in advance.



 Comments   
Comment by Javad Rahimi [ 26/Jun/15 ]

A temporary solution might be to change the function as:

DoctrineDBALplatformsSQLServer2005Platform.php
// Used NTEXT instead
public function getClobTypeDeclartionSQL(array $field)
{
     return 'NTEXT';
}

It will fix the partially but as you know NTEXT will omit lots of functionalities on different SELECT queries and it's going to be deprecated by Microsoft.

I hope someone could find a better solution for this issue.





[DBAL-1232] [GH-856] MySQL getListTableForeignKeysSQL: use current database if null passed Created: 18/May/15  Updated: 18/May/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 naderman:

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

Message:

In line with the behavior of `getListTableIndexesSQL()` the foreign key function should select only foreign keys from the current database if no database name is specified. Otherwise it returns foreign keys of all tables in any database with the given name. This can especially lead to issues if you install different versions of the same schema into multiple databases on the same server.

This function is always called with `$database = null` in the following chain, which leads to SQL errors when trying to setup/delete a schema in tests on a mysql server that contains another copy of the schema in another database:

```
Doctrine\ORM\Tools\SchemaTool::dropDatabase()
Doctrine\ORM\Tools\SchemaTool::getDropDatabaseSQL()
Doctrine\DBAL\Schema\AbstractSchemaManager::createSchema()
Doctrine\DBAL\Schema\AbstractSchemaManager::listTables()
Doctrine\DBAL\Schema\AbstractSchemaManager::listTableDetails($tableName)
Doctrine\DBAL\Schema\AbstractSchemaManager::listTableForeignKeys($table, null)
Doctrine\DBAL\Platforms\MySqlPlatform::getListTableForeignKeysSQL($table, null)
```

I think the `$database` parameter would ideally be required, and an exception should be thrown if it is null. The AbstractSchemaManager should be modified to consistently pass the database name to the platform in all its calls. But for now this workaround corrects the issue for foreign keys.






[DBAL-1231] [GH-855] Connection::ping() no longer produces warnings on connection timeout Created: 16/May/15  Updated: 16/May/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 fprochazka:

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

Message:

With PDOMySQL (I haven't tested other drivers), the ping call produces warnings, that IMHO should be handled by the library.

Because the test suite is ignoring warnings and notices, I assume nobody noticed this before. But our application has strict no-errors policy.
I've created similar temporary-hotfix https://github.com/Kdyby/Doctrine/commit/f7250e5b771eb1ba6c0abe23cb2dc689247d1b4c for my integration lib with Nette, but I believe that this is best handled on the library level.

I was considering adding a global error handler to bootstrap file, but that broke several other tests so that should be IMHO taken care of in separate pullrq.






[DBAL-1230] timestamp not supported, although no timestamp is ever defined Created: 15/May/15  Updated: 15/May/15

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

Type: Bug Priority: Major
Reporter: samuel liu Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

windows 8, sqlserver2008



 Description   

as I tried to run doctrine validate or schema update, following error message came up, although NO timestamp data type is ever used in my bundle.

[Doctrine\DBAL\DBALException] Unknown database type timestamp requested, Doctrine\DBAL\Platforms\SQLServer2008Platform may not support it






[DBAL-1229] Escape underscore when ignoring pg_ schemas in PostgreSqlPlatform Created: 12/May/15  Updated: 12/May/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: Tom Ploskina Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

In PostgreSqlPlatform.php, there are 3 lines (240,264,263) which query for schema by:

LIKE 'pg_%'

The underscore needs to be escaped:

LIKE 'pgBACKSLASH_%'

If you have a schema that starts with pg, for example, "pglims", the _ will not be evaluated and the tables, views and sequences returned will not include your tables. Our company's initials are PG by coincidence so we name our schemas accordingly. I will create a pull request for this issue.






[DBAL-1228] [GH-854] DateInterval Type Created: 09/May/15  Updated: 04/Jun/15

Status: Open
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: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: mapping


 Description   

This issue is created automatically through a Github pull request on behalf of v-bartusevicius:

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

Message:

Added DateInterval Type to store/receive PHP DateInterval objects.
Internally DateInterval is converted to string to store in VARCHAR field.
For maximum performance full DateInterval format is used when converting to database value.



 Comments   
Comment by Valentas [ 04/Jun/15 ]

Any news on this feature?





[DBAL-1227] Comparator finding diff for custom mapping type Created: 07/May/15  Updated: 07/May/15

Status: Open
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: Danny van der Sluijs Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: dbal, mapping, schematool


 Description   

When having a custom mapping type Filter

<?php

namespace MyProject\DBAL\Types;

use Doctrine\DBAL\Types\Type;
use Doctrine\DBAL\Platforms\AbstractPlatform;
use MyProject\Types\Filter as FilterType;

class Filter extends Type
{
    const TYPE = 'filter';

    public function convertToPHPValue($value, AbstractPlatform $platform)
    {
        return new FilterType($value);
    }

    public function convertToDatabaseValue($value, AbstractPlatform $platform)
    {
        return (string) $value;
    }

    public function getName()
    {
        return Filter::TYPE;
    }
}

The cli command orm:schema-tool:update keeps outputting the changes:

ALTER TABLE my_table ALTER filter TYPE VARCHAR(255);
ALTER TABLE my_table ALTER filter DROP DEFAULT;

When doing some debugging I've found this is caused by //lib/Doctrine/DBAL/Schema/Comparator.php at line 429
https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Schema/Comparator.php#L429

Where the compared values are:
Doctrine\DBAL\Types\StringType vs MyProject\DBAL\Types\Filter

In the application bootstrap the custom type is registered as a type, and is registered as a doctrine type mapping

Type::addType('filter', '\PersonalWebsite\DBAL\Types\Filter');

        $conn = $em->getConnection();
        $conn->getDatabasePlatform()->registerDoctrineTypeMapping('filter', 'filter');

        return $this;





[DBAL-1226] [GH-853] Remove HHVM-nightly builds Created: 06/May/15  Updated: 06/May/15  Resolved: 06/May/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: ci, hhvm-nightly, testing, travis

Issue Links:
Reference
relates to DDC-3726 [GH-1401] Remove HHVM-nightly builds Resolved

 Description   

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

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

Message:

This is similar to https://github.com/doctrine/doctrine2/pull/1401

This also simplies the allowed failures for HHVM



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

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





[DBAL-1225] [GH-852] Add SQL Anywhere builds to Travis Created: 06/May/15  Updated: 17/Jun/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 deeky666:

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

Message:

This is an attempt to enable functional testing for SQL Anywhere 12 + 16 on Travis.
It uses precompiled `sqlanywhere` PHP extensions for 5.3, 5.4, 5.5 and 5.6. Server-wise it uses preinstalled, lightweight packages (around 15 MB). This allows for a fast environment setup.
The packages reside on my Google Drive account, the URLs for the server packages are secured by Travis encryption.
The only downside of using secured environment variables is, that builds won't work on forks because of different SSH keys but that is a fair trade-off IMO.

/cc @zeroedin-bill @Ocramius @beberlei thoughts?



 Comments   
Comment by Doctrine Bot [ 17/Jun/15 ]

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

Comment by Doctrine Bot [ 17/Jun/15 ]

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





[DBAL-1224] [GH-851] Change MySQL defaults from broken utf8 to fixed utf8mb4 Created: 04/May/15  Updated: 06/May/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 DHager:

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

Message:

This is a conservative echo of https://github.com/doctrine/dbal/pull/317 .

Essentially MySQL's `uft8` character set is broken and does not support full UTF-8, and a better alternative, `utf8mb4` has existed for about five years now. Insofar as Doctrine has a MySQL default configuration, `utf8mb4` is a better choice.



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

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

Comment by Doctrine Bot [ 06/May/15 ]

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





[DBAL-1223] Doctrine migration diff not using column name annotation in traits Created: 04/May/15  Updated: 04/May/15  Resolved: 04/May/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: Mathieu Dumoulin Assignee: Benjamin Eberlei
Resolution: Incomplete Votes: 0
Labels: None
Environment:

PHP 5.6, latest composer version and latest version of Doctrine-Bundle for Symfony 2



 Description   

We are using a trait to define fields for "created_at" and "updated_at" in our entities and just realized that the:

use Doctrine\ORM\Mapping as ORM;
/*

  • @ORM\Column(name="created_at", type="datetime", nullable=true)
    */

is not enforced correctly when updating the database. It creates the field as "createdAt" in our database version 2 and the migration scripts to migrate version 1 to version 2 created provide the same behavior and try to rename the correct database version 1 field "created_at" to "createdAt" which is wrong.

I've tested this by placing the same code in an entity not using the trait and running diff now creates the field in the database using "created_at".



 Comments   
Comment by Mathieu Dumoulin [ 04/May/15 ]

Cancel this, we found the problem to be localized to our install, code was incorrect in several bundles and refered to a completely remote class...





[DBAL-1222] [GH-850] Allow to specify a charset and collation per column for Mysql Created: 03/May/15  Updated: 03/May/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 Freeaqingme:

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

Message:






[DBAL-1221] Wrong dsn when using postgresql with pdo Created: 02/May/15  Updated: 02/May/15  Resolved: 02/May/15

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

Type: Bug Priority: Major
Reporter: Karim Assignee: Steve Müller
Resolution: Duplicate Votes: 0
Labels: dbal, dsn, postgresql
Environment:

Symfony 2.6 on Linux Fedora 21 using PHP 5.6.8


Issue Links:
Duplicate
duplicates DBAL-1215 [GH-844] template1 as default databas... Resolved

 Description   

When I trying to create database using command line from Symfony framework, an error occurs :
[Doctrine\DBAL\Exception\ConnectionException]
An exception occured in driver: SQLSTATE[08006] [7] FATAL: database « myUserName » does not exists.

I tried to check what is wrong and I found that if in the class Doctrine\DBAL\Driver\PDOPgSql\Driver, in _constructPdoDsn method, i explicitly set the dbname like : $params['dbname'] = "myDb"; , it works.



 Comments   
Comment by Steve Müller [ 02/May/15 ]

Duplicate of DBAL-1215.





[DBAL-1220] [GH-849] Fix dropping database with active connection on PostgreSQL Created: 01/May/15  Updated: 17/Jun/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 deeky666:

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

Message:

PostgreSQL fails to drop a database if there are active connections using that particular database.
This PR closes all active connections before dropping the database if dropping the database failed before.



 Comments   
Comment by Doctrine Bot [ 17/Jun/15 ]

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





[DBAL-1219] [GH-848] [DBAL-1219] Add missing functional driver test cases Created: 30/Apr/15  Updated: 30/Apr/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 deeky666:

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

Message:






[DBAL-1218] [GH-847] [DBAL-1217] Fix retrieving the database name connected to for SQL Anywhere Created: 30/Apr/15  Updated: 30/Apr/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 deeky666:

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

Message:

When connecting to SQL Anywhere without `dbname` parameter set, the underlying driver emits a `undefined index "dbname"` when trying to retrieve the database name connected to via `Doctrine\DBAL\Driver::getDatabase()`.
This PR implements the "live" retrieval of the current database as seen in other drivers already.






[DBAL-1217] [GH-846] Fix retrieving the database name connected to for SQL Server Created: 30/Apr/15  Updated: 30/Apr/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 deeky666:

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

Message:

When connecting to SQL Server without `dbname` parameter set, the underlying driver emits a `undefined index "dbname"` when trying to retrieve the database name connected to via `Doctrine\DBAL\Driver::getDatabase()`.
This PR implements the "live" retrieval of the current database as seen in other drivers already.






[DBAL-1216] [GH-845] Dbal 1215 Created: 30/Apr/15  Updated: 30/Apr/15  Resolved: 30/Apr/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 mikeSimonson:

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

Message:



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

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





[DBAL-1215] [GH-844] template1 as default database for PostgreSQL Created: 29/Apr/15  Updated: 02/May/15  Resolved: 30/Apr/15

Status: Resolved
Project: Doctrine DBAL
Component/s: Drivers
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: dbname, pdo_pgsql, pgsql, postgresql, template1

Issue Links:
Duplicate
is duplicated by DBAL-1221 Wrong dsn when using postgresql with pdo Resolved

 Description   

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

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

Message:

Fixes (including but not limited to) https://github.com/doctrine/DoctrineBundle/issues/402 by connecting by default to 'template1' instead of the database with the same name as the user (PostgreSQL default in case of no dbname).



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

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





[DBAL-1214] MySQL has gone away using ImportCommand Created: 29/Apr/15  Updated: 29/Apr/15

Status: Open
Project: Doctrine DBAL
Component/s: None
Affects Version/s: 2.3.4
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Sylvain Filteau Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Importing a fairly large SQL file (a MySQL dump) fails with a MySQL has gone away error.

When reading the ImportCommand code, I see that this issue is already "fixed" by checking if the connection is an instance of `\Doctrine\DBAL\Driver\PDOConnection`.

The problem is that I don't see how the connection could be an instance of this class since it doesn't extend `\Doctrine\DBAL\Connection`.

If I'm wrong, then I don't know how to configure my connection to extend the PDOConnection class. Thanks for your help on that






[DBAL-1213] [GH-843] fix TypeHinting for method parameter 'convertToPHPValueSQL' Created: 28/Apr/15  Updated: 29/Apr/15  Resolved: 29/Apr/15

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Can't Fix Votes: 0
Labels: parameter, type, type-hinting


 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 29/Apr/15 ]

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

Comment by Doctrine Bot [ 29/Apr/15 ]

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

Comment by Marco Pivetta [ 29/Apr/15 ]

Closing since it is a BC break





[DBAL-1212] Array as result of getXxxxSql functions in Platforms Created: 28/Apr/15  Updated: 28/Apr/15

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

Type: Improvement Priority: Minor
Reporter: Andreas Prucha Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

It's possible to return an array of SQL-Statements in getAlterTableSql, CreateTableSql etc because the Schema-Classes handle them as an array and merge the result. Unfortunately in many cases (like getDropTable), the result is not merged, but addes as single array item:

$sql[] = $platform->getDropTableSQL($table);

Thus, it's not possible to return multiple statements there. This does not hurt in most cases, but drivers might need to perform additional statements (e.g. drop a trigger or drop related views).

This is obviously the case in the Oracle-Driver and it's also necessary in the Firebird driver.

I think it might be better to allow arrays as result everywhere. Of course it's possible to workaround the limitation by combing multiple statements into a single "execute block"-statement, but an array of statements as result would be cleaner and easier.






[DBAL-1211] Wrapper Class should enforce a Interface not a Subclass Created: 27/Apr/15  Updated: 27/Apr/15

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

Type: Improvement Priority: Major
Reporter: Flavio Botelho Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: dbal


 Description   

We are creating a Wrapper Class to allow the use of the Oracle Proxy User feature. For that I need to Wrapper a Class around DBAL\Connection.
Unfortunely, the wrapper class needs to be a subclass of DBAL\Connection which doesn't make sense, there should exist an Interface and the wrapper class should be forced to implement that interface.

That way I don't need to create methods to call all DBAL\Connection methods thru polymorphism.






[DBAL-1210] [GH-842] Fixed incorrect handling of single quotes in SQL-Strings Created: 26/Apr/15  Updated: 26/Apr/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 ancpru:

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

Message:

escaped by repeated single-quote (DBAL-1205)






[DBAL-1209] [GH-841] Documentation & code styling fixes Created: 25/Apr/15  Updated: 30/Apr/15  Resolved: 30/Apr/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: Steve Müller
Resolution: Fixed Votes: 0
Labels: code-style, cs, phpdoc


 Description   

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

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

Message:

This fixes:

  • incorrect / incomplete / missing PHPdoc
  • wrong case for method names
  • unused imports


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

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





[DBAL-1208] [GH-840] Driver for SQLite3 Created: 25/Apr/15  Updated: 25/Apr/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 BenMorel:

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

Message:

This PR adds an additional driver using the [SQLite3](http://php.net/manual/fr/book.sqlite3.php) class, in addition to the PDO_SQLITE driver.

    1. Why this driver?

Even though the PDO SQLite driver is already available to interact with SQLite databases, PDO currently has a big limitation: it [does not allow to load SQLite extensions](https://bugs.php.net/bug.php?id=64810).

This functionality is provided by the `SQLite3` class, which becomes your only option if you need to use your PHP application with an SQLite extension such as [SpatiaLite](http://www.gaia-gis.it/gaia-sins/).






[DBAL-1207] Schema Update Issue with DBAL 2.5 Binary Type Created: 24/Apr/15  Updated: 18/May/15

Status: Open
Project: Doctrine DBAL
Component/s: Schema Managers
Affects Version/s: 2.5
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Alex Gurrola Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: schematool
Environment:

Ubuntu 14.04.2 LTS, Apache 2.4.7, PHP 2.5.9, MySQL 5.5, Symfony 2.6.6



 Description   

Every time I run a doctrine:schema:update command within Symfony, using DBAL 2.5, it tries to execute this SQL Query, every single time:

SQL Query
ALTER TABLE user_sessions CHANGE sess_id sess_id VARBINARY(128) NOT NULL;

The PHP Annotations I am using for this column is as follows:

Binary Column
/**
 * @var string
 *
 * @ORM\Column(name="sess_id", type="binary", length=128, nullable=false)
 * @ORM\Id
 * @ORM\GeneratedValue(strategy="IDENTITY")
 */
private $sessId;

It seems the binary type is somehow registering a change even though no change has actually been made. I updated to DBAL to 2.5 before getting the binary type supported by the doctrine:schema:update command.

Thanks in advance for any assistance in squashing this odd bug.

--Alex Gurrola



 Comments   
Comment by Nate Baker [ 15/May/15 ]

Do you intentionally have @ORM\GeneratedValue(strategy="IDENTITY"), or is that there from an auto import? I had the same problem but if I changed to strategy="NONE" it doesn't happen anymore. See this issue: http://www.doctrine-project.org/jira/browse/DBAL-353

Comment by Alex Gurrola [ 18/May/15 ]

It was an auto import. Your link resolved the issue, thanks.





[DBAL-1206] Generating Table SQL without indexes is invalid if using AUTO_INCREMENT Created: 24/Apr/15  Updated: 24/Apr/15

Status: Open
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: None
Fix Version/s: None

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

MySQL (but maybe other database vendors too)



 Description   

Dumping the following table

CREATE TABLE `users` (
    `id` INT AUTO_INCREMENT NOT NULL,
    PRIMARY KEY (`id`)
);

with the following snippet (0 = NoIndexes)

$platform->getCreateTableSQL($table, 0);

results in


CREATE TABLE `users` (
    `id` INT AUTO_INCREMENT NOT NULL,
);

The problem is, that the table contains an AUTO_INCREMENT column which cannot be used without a primary key. But the primary key is skipped, as I skipped all indexes.

As this SQL is invalid, I suggest to skip the AUTO_INCREMENT argument, too, if the indexes are skipped. Alternatively, the Primary Key always has to be included.

What do you think? I can provide a fix, if you agree with me.






[DBAL-1205] getPlaceholderPositions finds placeholders which are actually no placeholder if string contains single quotes Created: 24/Apr/15  Updated: 13/Jul/15

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

Type: Bug Priority: Critical
Reporter: Andreas Prucha Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

The following statement obviously does not contain any parameters:

select
'quoted1 '' :not_a_param1 quoted2 "'':not_a_param2''" ''' foo
from rdb$database

But the following call:

$params = \Doctrine\DBAL\SQLParserUtils::getPlaceholderPositions
('select \'quoted1 \'\' :not_a_param1 quoted2 "\'\':not_a_param2\'\'" \'\'\' foo from rdb$database', false);

returns

(
[19] => not_a_param1
)

It seems that getUnquotedStatementFragments() does not handle escaping by doubling single quotes correctly.



 Comments   
Comment by Dalibor Petras [ 13/Jul/15 ]

I hit similar issue, the root cause is that: SINGLE quote escaped by SINGLE quote (SQL Server syntax) is not interpreted correctly in SQLParserUtils::getUnquotedStatementFragments().

In my test scenario

SELECT 'O''hara' as test FROM sometable WHERE somecolumn = :myPlaceholder AND otherColumn NOT IN ( 'Test')

getPlaceholderPositions wont find any place holder.

I made crude fix and added both scenarios (reported by Andreas Prucha and my) to unit test. See my fork https://github.com/isp0000/dbal/tree/DBAL-1205

Not sure if this is pull request worthy.





[DBAL-1204] Description of SQLParserUtils::getPlaceholderPositions() misleading Created: 24/Apr/15  Updated: 24/Apr/15

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

Type: Documentation Priority: Trivial
Reporter: Andreas Prucha Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

The description of this function is slightly misleading:

>> Returns an integer => integer pair (indexed from zero) for a positional statement and a string => int[] pair for a named statement. <<

This seems to be correct for positional parameters, but wrong for named parameters. According to the description i would expect the parameter names as keys and the positions as values, but the function returns an array with positions as key, and the parameter name of the position as value.






[DBAL-1203] [GH-839] Dbal 1200 Created: 22/Apr/15  Updated: 22/Apr/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 jbh-:

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

Message:

Add order by support in modify limit function for DB2. This takes care of DBAL-122(http://www.doctrine-project.org/jira/browse/DBAL-1200).

The current tests pass.






[DBAL-1202] JoinTable causes table already exists exception to be flung Created: 22/Apr/15  Updated: 22/Apr/15

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

Type: Bug Priority: Major
Reporter: Iain Cambridge Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: None


 Description   
/**
     * @var Collection
     * @ORM\ManyToMany(targetEntity="Foodpanda\Bundle\Core\CmsBundle\Entity\Tag", inversedBy="cmsPages")
     * @JoinTable(name="CmsCmsTags")
    */

The @JoinTable causes the exception to be flung when running schema create



 Comments   
Comment by Marco Pivetta [ 22/Apr/15 ]

Can't reproduce: please design a test case around the failure.

Comment by Iain Cambridge [ 22/Apr/15 ]

Can what you did to try and reproduce?

Comment by Iain Cambridge [ 22/Apr/15 ]

Also how are you guys even testing this? I can't see, therefore can't write a breaking test.

Comment by Marco Pivetta [ 22/Apr/15 ]

Iain Cambridge I created a test like following:

<?php

namespace Doctrine\Tests\ORM\Functional\Ticket;

/**
 * @group DDC-1452
 */
class DDC1452Test extends \Doctrine\Tests\OrmFunctionalTestCase
{
    protected function setUp()
    {
        parent::setUp();

        try {
            $this->_schemaTool->dropSchema(array(
                $this->_em->getClassMetadata(DDC9999EntityA::CLASSNAME),
                $this->_em->getClassMetadata(DDC9999EntityB::CLASSNAME),
            ));
        } catch (\Exception $e) {
            // ignored
        }
    }

    public function testIssue()
    {
        $this->_schemaTool->createSchema(array(
            $this->_em->getClassMetadata(DDC9999EntityA::CLASSNAME),
            $this->_em->getClassMetadata(DDC9999EntityB::CLASSNAME),
        ));
    }
}

/** @Entity */
class DDC9999EntityA
{
    const CLASSNAME = __CLASS__;

    /** @Id @Column(type="integer") @GeneratedValue */
    private $id;

    /**
     * @ORM\ManyToMany(targetEntity=DDC9999EntityB::class)
     * @JoinTable(name="CmsCmsTags")
     */
    private $b;
}

/** @Entity */
class DDC9999EntityB
{
    const CLASSNAME = __CLASS__;

    /** @Id @Column(type="integer") @GeneratedValue */
    private $id;
}
Comment by Iain Cambridge [ 22/Apr/15 ]

Thanks, so the test has to be in the ORM package?

Comment by Marco Pivetta [ 22/Apr/15 ]

Iain Cambridge yes, since it seems to be a mapping issue - see https://github.com/doctrine/doctrine2/tree/v2.5.0/tests/Doctrine/Tests/ORM/Functional/Ticket

Comment by Iain Cambridge [ 22/Apr/15 ]

This below fails for me.

<?php

namespace Doctrine\Tests\ORM\Functional\Ticket;

/**
 * @group DBAL-1202
 */
class DBAL1202Test extends \Doctrine\Tests\OrmFunctionalTestCase
{
    protected function setUp()
    {
        parent::setUp();

        try {
            $this->_schemaTool->dropSchema(array(
                $this->_em->getClassMetadata(DDC9999EntityA::CLASSNAME),
                $this->_em->getClassMetadata(DDC9999EntityB::CLASSNAME),
                $this->_em->getClassMetadata(DDC9999EntityC::CLASSNAME),
            ));
        } catch (\Exception $e) {
            // ignored
        }
    }

    public function testIssue()
    {
      var_dump($this->_em->getClassMetadata(DDC9999EntityA::CLASSNAME));
        $this->_schemaTool->createSchema(array(
            $this->_em->getClassMetadata(DDC9999EntityA::CLASSNAME),
            $this->_em->getClassMetadata(DDC9999EntityB::CLASSNAME),
            $this->_em->getClassMetadata(DDC9999EntityC::CLASSNAME),
        ));
    }
}

/** @Entity */
class DDC9999EntityA
{
    const CLASSNAME = __CLASS__;

    /** @Id @Column(type="integer") @GeneratedValue */
    private $id;

    /**

     * @ManyToMany(targetEntity=DDC9999EntityC::class)
     * @JoinTable(name="CmsCmsTags")
     */
    private $b;
}

/**
 * @Entity
 * @Table(
 *      name="CmsCmstags",
 * )
 */
class DDC9999EntityB
{
    const CLASSNAME = __CLASS__;

    /** @Id @Column(type="integer") @GeneratedValue */
    private $id;

}

/**
  * @Entity
  * @Table(
  *      name="Cmstags",
  * )
  */
class DDC9999EntityC
{
    const CLASSNAME = __CLASS__;

    /** @Id @Column(type="integer") @GeneratedValue */
    private $id;
}

Comment by Marco Pivetta [ 22/Apr/15 ]

Seems an obvious failure to me - two declarations for the same table. What's the bug?

Comment by Iain Cambridge [ 22/Apr/15 ]

One entity uses cmscmstags and another cmstags. (Don't ask me why, just started)

Comment by Marco Pivetta [ 22/Apr/15 ]

Iain Cambridge I see that DDC9999EntityB has @Table(name="CmsCmstags"), and there is also a @JoinTable(name="CmsCmsTags")

Comment by Iain Cambridge [ 22/Apr/15 ]

I thought @table defines the table name for an entity. With @jointable defines the table to be used for a join. Are you saying they both define tables?

Comment by Marco Pivetta [ 22/Apr/15 ]

Yes, both cause a new table to be created on the DB.

Comment by Iain Cambridge [ 22/Apr/15 ]

I figured they would caused tables to be created but I wouldn't expect defining a join to cause an exception of defining a table twice. Especially since it seems quite possible and logical to use @JoinTable more than once?

Another quite possible and logical example would be one big entity and then only wanting a subset of that data for a join so use a smaller entity to hold that data.

Not saying the use case provided is exactly sane, however I would expect it to work.





[DBAL-1201] [GH-838] DBAL-95 Firebird Driver, Platform and Schema Manager Created: 22/Apr/15  Updated: 22/Apr/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 ancpru:

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

Message:

Hi,

I've implemented the driver for Firebird. It's currently tested with FB 2.5.

The driver uses the ibase-api. Originally I also had a PDO-based implementation. Despite it worked quite well in a real world application, it terribly failed in the Doctrine test suite because of strange transaction behaviour of the Firebird-PDO, thus I finally removed it.

The name of the driver is ibase_firebird, the platform name is firebird.

Because of the common ancestor Firebird an Interbase, it should be possible to use the implementation for Interbase, too. But this is not done nore tested, yet.

Andreas






[DBAL-1200] DB2 Platform doModifyLimitQuery ORDER BY Created: 21/Apr/15  Updated: 21/Apr/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: Mark Gullings Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

IBM i v7r1



 Description   

Implement TODO note in doModifyLimitQuery

DB2Platform.php
    protected function doModifyLimitQuery($query, $limit, $offset = null)
    {
        if ($limit === null && $offset === null) {
            return $query;
        }
        $limit = (int) $limit;
        $offset = (int) (($offset)?:0);
        // Todo OVER() needs ORDER BY data!
        $sql = 'SELECT db22.* FROM (SELECT ROW_NUMBER() OVER() AS DC_ROWNUM, db21.* '.
               'FROM (' . $query . ') db21) db22 WHERE db22.DC_ROWNUM BETWEEN ' . ($offset+1) .' AND ' . ($offset+$limit);
        return $sql;
    }


 Comments   
Comment by Mark Gullings [ 21/Apr/15 ]

solution is in testing locally





[DBAL-1199] [GH-837] Revert the addition of the wrong bin script Created: 15/Apr/15  Updated: 01/May/15  Resolved: 30/Apr/15

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

Type: Bug Priority: Minor
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: cli, composer, tools


 Description   

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

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

Message:

The bin/doctrine-dbal.php file is not an executable file. Adding them as a bin in composer.json means that any composer install will trigger changes in the source when using symlinks because of the chmod. This makes things a pain when installing from source.
Thus, there is no valid reason to add it. It is absolutely not necessary when using a composer install. The issue requesting it previously is actually an issue in Laravel which replaces the proxy file/symlink generated by Composer with a copy of the original file, which of course cannot work because of paths used in require. But copying a second file does not help for that (unless in very specific cases). It only moves the issue until the next require call.



 Comments   
Comment by Doctrine Bot [ 15/Apr/15 ]

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

Comment by Doctrine Bot [ 30/Apr/15 ]

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





[DBAL-1198] [GH-836] Merge pull request #2 from doctrine/master Created: 10/Apr/15  Updated: 13/Apr/15  Resolved: 13/Apr/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 ancpru:

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

Message:

upd



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

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





[DBAL-1197] [GH-835] backport bugfix to avoid fatal error in array_merge during generating the table creation SQL Created: 10/Apr/15  Updated: 30/Apr/15  Resolved: 30/Apr/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: create-schema, create-table, sql-collector


 Description   

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

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

Message:

2.5 includes this fix in 1c9fe8df . this pull request is just to backport the bugfix without further changes.

i verified on https://github.com/jackalope/jackalope-doctrine-dbal/pull/258 that this change indeed fixes the issue - but i don't know how to write a test for this.



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

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

Comment by Doctrine Bot [ 30/Apr/15 ]

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





[DBAL-1196] [GH-834] Update Connection.php Created: 09/Apr/15  Updated: 16/Apr/15  Resolved: 09/Apr/15

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: Trivial
Reporter: Doctrine Bot Assignee: Bill Schaller
Resolution: Fixed Votes: 0
Labels: connection, docblock, documentation, event


 Description   

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

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

Message:

These events don't exist.



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

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

Comment by Doctrine Bot [ 09/Apr/15 ]

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





[DBAL-1195] [GH-833] [DX] Added bool and int types Created: 09/Apr/15  Updated: 10/Apr/15  Resolved: 10/Apr/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: bool, int, types


 Description   

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

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

Message:

Lately we have done similar thing for MongoDB ODM in https://github.com/doctrine/mongodb-odm/pull/1073 so I thought it will add value to DBAL as well. I've also changed ``integer`` and ``boolean`` to ``bool`` and ``int`` when used in PHP context. If this will be merged I can submit a PR to ORM docs as well



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

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





[DBAL-1194] [GH-832] Fix test failures on windows due to differing newlines Created: 08/Apr/15  Updated: 15/Apr/15  Resolved: 15/Apr/15

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

Type: Bug Priority: Minor
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: ci, newlines, tests, testsuite, windows


 Description   

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

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

Message:

Some tests were failing on windows due to differing newlines.

The tests which were failing used inline newlines in the comparison string, which evaluate to \r\n on Windows and \n on *nix.

The tests have been changed to use explicit newlines "\n".

Failure messages:
```
E:\wwwroot\dbal>vendor\bin\phpunit -c nodb.xml --filter "(testGetPlaceholderPositions|testDriverExceptionIsWrapped)" tests\Doctrine\Tests\DBAL
PHPUnit 4.0.20 by Sebastian Bergmann.

Configuration read from E:\wwwroot\dbal\nodb.xml

FFFFF.....................F............

Time: 2.8 seconds, Memory: 33.25Mb

There were 6 failures:

1) Doctrine\Tests\DBAL\ConnectionTest::testDriverExceptionIsWrapped with data set #0 ('exec')
Failed asserting that exception message 'An exception occurred while executing 'MUUHAAAAHAAAA':

SQLSTATE[HY000]: General error: 1 near "MUUHAAAAHAAAA": syntax error' contains 'An exception occurred while executing 'MUUHAAAAHAAAA':

SQLSTATE[HY000]: General error: 1 near "MUUHAAAAHAAAA"'.

2) Doctrine\Tests\DBAL\ConnectionTest::testDriverExceptionIsWrapped with data set #1 ('query')
Failed asserting that exception message 'An exception occurred while executing 'MUUHAAAAHAAAA':

SQLSTATE[HY000]: General error: 1 near "MUUHAAAAHAAAA": syntax error' contains 'An exception occurred while executing 'MUUHAAAAHAAAA':

SQLSTATE[HY000]: General error: 1 near "MUUHAAAAHAAAA"'.

3) Doctrine\Tests\DBAL\ConnectionTest::testDriverExceptionIsWrapped with data set #2 ('executeQuery')
Failed asserting that exception message 'An exception occurred while executing 'MUUHAAAAHAAAA':

SQLSTATE[HY000]: General error: 1 near "MUUHAAAAHAAAA": syntax error' contains 'An exception occurred while executing 'MUUHAAAAHAAAA':

SQLSTATE[HY000]: General error: 1 near "MUUHAAAAHAAAA"'.

4) Doctrine\Tests\DBAL\ConnectionTest::testDriverExceptionIsWrapped with data set #3 ('executeUpdate')
Failed asserting that exception message 'An exception occurred while executing 'MUUHAAAAHAAAA':

SQLSTATE[HY000]: General error: 1 near "MUUHAAAAHAAAA": syntax error' contains 'An exception occurred while executing 'MUUHAAAAHAAAA':

SQLSTATE[HY000]: General error: 1 near "MUUHAAAAHAAAA"'.

5) Doctrine\Tests\DBAL\ConnectionTest::testDriverExceptionIsWrapped with data set #4 ('prepare')
Failed asserting that exception message 'An exception occurred while executing 'MUUHAAAAHAAAA':

SQLSTATE[HY000]: General error: 1 near "MUUHAAAAHAAAA": syntax error' contains 'An exception occurred while executing 'MUUHAAAAHAAAA':

SQLSTATE[HY000]: General error: 1 near "MUUHAAAAHAAAA"'.

6) Doctrine\Tests\DBAL\SQLParserUtilsTest::testGetPlaceholderPositions with data set #21 ('SELECT * FROM foo WHERE bar = \'it\\\'s a trap? \\\\\' OR bar = ?
AND baz = "\\"quote
" me on it? \\\\" OR baz = ?', true, array(58, 104))
Failed asserting that two arrays are equal.
— Expected
+++ Actual
@@ @@
Array (
0 => 58

  • 1 => 104
    + 1 => 105
    )

E:\wwwroot\dbal\tests\Doctrine\Tests\DBAL\SQLParserUtilsTest.php:71

FAILURES!
Tests: 39, Assertions: 44, Failures: 6.
```



 Comments   
Comment by Doctrine Bot [ 15/Apr/15 ]

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





[DBAL-1193] "requiresSQLCommentHint" is ignored by migration if the SQL type does not change Created: 08/Apr/15  Updated: 08/Apr/15

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

Type: Bug Priority: Major
Reporter: Varga Bence Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

I have found a previous issue, http://www.doctrine-project.org/jira/browse/DBAL-1085 which tells about the need to override "requiresSQLCommentHint" if the custom type uses an SQL type which is already known by Doctrine.

See also:
https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Types/Type.php#L327-L340

The bug: After I learned this and added the required TRUE return value, the migration (generated by "diff") won't contain the comment.

After adding the comment manually, everything works as expected.






[DBAL-1192] [GH-831] allow hhvm/mysqli failure so poor travis can feel better Created: 05/Apr/15  Updated: 05/Apr/15  Resolved: 05/Apr/15

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

Type: Bug Priority: Minor
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: allow-failures, ci, hhvm, mysqli, travis


 Description   

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

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

Message:



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

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

Comment by Doctrine Bot [ 05/Apr/15 ]

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





[DBAL-1191] [GH-830] Readme: nicer badges; cleanup, 2.3- dropped Created: 03/Apr/15  Updated: 07/Apr/15  Resolved: 07/Apr/15

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

Type: Documentation Priority: Minor
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: Documentation


 Description   

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

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

Message:

Ref https://github.com/doctrine/doctrine2/pull/1362

Is there any reason why coverage is not in here? Would be much more useful than dependency badge.



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

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

Comment by Doctrine Bot [ 03/Apr/15 ]

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

Comment by Doctrine Bot [ 03/Apr/15 ]

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

Comment by Doctrine Bot [ 07/Apr/15 ]

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





[DBAL-1190] [GH-829] Pgsql connection test with charset parameter Created: 02/Apr/15  Updated: 30/Apr/15

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

Type: Improvement Priority: Minor
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Unresolved Votes: 0
Labels: charset, client_encoding, pdo_pgsql, pgbouncer, pgsql, postgresql, testing


 Description   

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

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

Message:

This PR adds 2 tests for connecting to pgsql via PDOPgSql, while using a charset parameter.

Related to #828, #823



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

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





[DBAL-1189] [GH-828] rehashed charset implementation to support old versions of postgresql Created: 02/Apr/15  Updated: 08/Apr/15  Resolved: 08/Apr/15

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

Type: Bug Priority: Minor
Reporter: Doctrine Bot Assignee: Bill Schaller
Resolution: Fixed Votes: 0
Labels: charset, client_encoding, connection, driver, dsn, pdo_pgsql, pgbouncer, pgsql, postgresql, set-names


 Description   

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

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

Message:

My previous client_encoding fix turned out not to work on older postgres versions – BUT, the options param isn't supported by pgbouncer at all. SO, because there isn't consistent behavior with setting the character set via DSN - this change utilizes `SET NAMES`. I used SET NAMES since that is SQL standard and supported by PG.

I confirmed `SET NAMES` is supported all the way back to the older doc PG has, 7.1: http://www.postgresql.org/docs/7.1/static/multibyte.html



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

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





[DBAL-1188] Oracle Platform: List table columns are returned in the wrong order Created: 01/Apr/15  Updated: 01/Apr/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: Martijn Evers Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

The function:

Doctrine\DBAL\Platforms\OraclePlatform::getListTableColumnsSQL

returns the columns sorted by name. This causes a problem in my application. Other platforms sort them on position. So when I build a model for a HTML table (placing datatype formatters for each column) the order of formatters gets messed up.

The equivalent method in other platforms like MySQL or PostgreSQL all make sure the order is preserved (the same as in the database).

To fix I changed

...ORDER BY c.column_name

to

...ORDER BY c.column_id





[DBAL-1187] [GH-827] Fix DISTINCT queries with limit and no order on SQL Server 2012 Created: 31/Mar/15  Updated: 08/Apr/15  Resolved: 08/Apr/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: limit, mssql, offset, query, select-distinct, sql-server, sql-server-2012, sqlsrv


 Description   

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

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

Message:

On SQLServer2012Platform, doModifyLimitQuery adds a do-nothing ORDER BY clause, because this is required in order to use OFFSET...FETCH NEXT N ROWS ONLY.

DISTINCT queries run via the paginator without an ORDER BY clause on SQL Server 2012 were failing with this error:

```
ORDER BY items must appear in the select list if SELECT DISTINCT is specified.
```

This PR fixes the error by adding 0 to the select list and changing the generated ORDER BY clause to read ORDER BY 1.

So a query that would have been generated as:
```sql
SELECT DISTINCT id_0
FROM (
SELECT p0_.id AS id_0
,p0_.preference_code AS preference_code_1
,p0_.id_zone AS id_zone_2
FROM preference p0_
WHERE (p0_.id_zone IN (2))
) dctrn_result
ORDER BY (SELECT 0)
OFFSET 0 ROWS FETCH NEXT 30 ROWS ONLY
```

Will now be generated as:
```sql
SELECT DISTINCT 0, id_0
FROM (
SELECT p0_.id AS id_0
,p0_.preference_code AS preference_code_1
,p0_.id_zone AS id_zone_2
FROM preference p0_
WHERE (p0_.id_zone IN (2))
) dctrn_result
ORDER BY 1
OFFSET 0 ROWS FETCH NEXT 30 ROWS ONLY
```



 Comments   
Comment by Doctrine Bot [ 08/Apr/15 ]

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





[DBAL-1186] [GH-826] fix incorrect ordering of columns in clustered indexes on sql server Created: 31/Mar/15  Updated: 16/Apr/15  Resolved: 16/Apr/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: Minor
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: clustered, columns, index, mssql, order, 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/826

Message:

When schema information is fetched from SQL server, the getListTableIndexesSQL was fetching index columns ordered by sys.index_columns.index_column_id. This was incorrect, because that column is simply a unique id for the column within the index. The column ordering information is actually in the key_ordinal column.

This PR changes SQLServerPlatform to generate a resultset ordered by key_ordinal instead of index_column_id.

This was causing schema diffs on tables with composite primary keys to try to drop and re-create the indexes every time the diff is run.

So this solves index churn in schema diffs on SQL server.



 Comments   
Comment by Doctrine Bot [ 15/Apr/15 ]

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





[DBAL-1185] [GH-825] Add postgresql 9.4 for travis builds Created: 30/Mar/15  Updated: 02/Apr/15  Resolved: 02/Apr/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: ci, pgsql, postgresql, testing, travis


 Description   

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

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

Message:



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

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





[DBAL-1184] [GH-824] Added Postgres 9.4 platform (DBAL-1143) Created: 29/Mar/15  Updated: 29/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 mbeccati:

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

Message:

Features and changes:

  • jsonb can be used with: options= {"jsonb"=true}
  • OVER is no longer reserved
  • LATERAL is now reserved





[DBAL-1183] [GH-823] fix client_encoding setting to support pgbouncer Created: 27/Mar/15  Updated: 27/Mar/15  Resolved: 27/Mar/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: Steve Müller
Resolution: Fixed Votes: 0
Labels: charset, client_encoding, pgbouncer, pgsql, postgresql

Issue Links:
Reference
relates to DBAL-567 PDOPgSql should respect connection ch... Resolved

 Description   

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

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

Message:

The current release doesn't allow connecting to pgbcouner when specifying the charset due to the lack of support for the 'options' parameter. The fix is to use the client_encoding option directly instead of passing it through the options parameter.

This exact same bug was fixed in node.js's PG driver the exact same way.

https://github.com/brianc/node-postgres/pull/356

I've confirmed this fix works with pgbouncer.



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

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





[DBAL-1182] No schema difference detected when changing length of a text field Created: 26/Mar/15  Updated: 26/Mar/15

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

Type: Bug Priority: Major
Reporter: Evan Sheffield Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: dbal, mysql, schema-tool
Environment:

Database: MySQL 5.6



 Description   

I have a text field with a length specified that causes it to be chosen as TINYTEXT in MySQL.

/**  
 * @ORM\Column(name="message", type="text", length=255,  nullable=true)
 */
protected $message;

When I remove the length field from the annotation, I would expect the field to then be interpreted as LONGTEXT as specified in the documentation. However, when I run orm:schematool:update, it says that there is nothing to update.






[DBAL-1181] [GH-822] Fix for bad profiling data, showing an indefinitely long query Created: 26/Mar/15  Updated: 08/Apr/15  Resolved: 08/Apr/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: Minor
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 1
Labels: logging, profiling


 Description   

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

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

Message:

This fix solves a problem where a failed transaction generates inaccurate profiling data.

In Symfony's "Timeline" profiler view, the bug makes it appear as if Symfony is taking a lot of time to process something, up until the very end of the request.



 Comments   
Comment by Doctrine Bot [ 08/Apr/15 ]

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





[DBAL-1180] [GH-821] Added method for switching support for foreign keys for SQLite Created: 25/Mar/15  Updated: 25/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 hason:

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

Message:






[DBAL-1179] [GH-820] SchemaManager quoting fixes Created: 19/Mar/15  Updated: 19/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: 1
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/820

Message:

The SchemaManager, when used with SQL Server, fails to quote incoming table names and column names that should be quoted. That means that when a table that exists in the database called 'quote-address' needs to be dropped, the drop table statement will fail because the identifer is not marked as quoted when the schema diff is created.

This patch adds a method isValidIdentifier to the AbstractPlatform API - the purpose of this is to check if an identifier is valid to be used in SQL on the platform.

This is used by a new protected method in AbstractSchemaManager, quoteIncomingIdentifier. This method checks if the passed string literal is a valid identifier using isValidIdentifier. If the identifier is not valid, it quotes it for the platform and returns it. If it is valid, or is already quoted, it returns the identifier unchanged.






[DBAL-1178] Mapping import errors on SQL Server 2000 Created: 19/Mar/15  Updated: 23/Mar/15

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

Type: Bug Priority: Critical
Reporter: Ciro Vargas Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: dbal, mapping, sqlserver
Environment:

Microsoft SQL Server 2000 - 8.00.2066 (Intel X86)
May 11 2012 18:41:14
Copyright (c) 1988-2003 Microsoft Corporation
Standard Edition on Windows NT 5.2 (Build 3790: Service Pack 2)


Attachments: PNG File System tables.png    

 Description   

The Doctrine documentation says:

SQLServerPlatform for version 2000 and above.

And the mapping query on the platform SQLServerPlatform.php is:

    public function getListTableColumnsSQL($table, $database = null)
    {
        return "SELECT    col.name,
                          type.name AS type,
                          col.max_length AS length,
                          ~col.is_nullable AS notnull,
                          def.definition AS [default],
                          col.scale,
                          col.precision,
                          col.is_identity AS autoincrement,
                          col.collation_name AS collation,
                          CAST(prop.value AS NVARCHAR(MAX)) AS comment -- CAST avoids driver error for sql_variant type
                FROM      sys.columns AS col
                JOIN      sys.types AS type
                ON        col.user_type_id = type.user_type_id
                JOIN      sys.objects AS obj
                ON        col.object_id = obj.object_id
                JOIN      sys.schemas AS scm
                ON        obj.schema_id = scm.schema_id
                LEFT JOIN sys.default_constraints def
                ON        col.default_object_id = def.object_id
                AND       col.object_id = def.parent_object_id
                LEFT JOIN sys.extended_properties AS prop
                ON        obj.object_id = prop.major_id
                AND       col.column_id = prop.minor_id
                AND       prop.name = 'MS_Description'
                WHERE     obj.type = 'U'
                AND       " . $this->getTableWhereClause($table, 'scm.name', 'obj.name');
    }

But the system tables in the database is (attached)

There are several errors in queries using tables and fields that do not exist in SQL Server (in all map methods). So I can not map the entities



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

Ciro Vargas we don't support SQLServer 2000: the oldest version we support is SQLServer 2005 as per https://github.com/doctrine/dbal/blob/3b901cd314d1f79a54c93131d634aad507114b34/lib/Doctrine/DBAL/Platforms/SQLServer2005Platform.php

Comment by Benjamin Eberlei [ 19/Mar/15 ]

This doesnt end the world for you, you must extend from the SQL Server platform and change what you need.

Comment by Ciro Vargas [ 19/Mar/15 ]

Marco Pivetta http://doctrine-dbal.readthedocs.org/en/latest/reference/platforms.html in the docs says:

"SQLServerPlatform for version 2000 and above."

The right way is create mapping querys in the version platform and override on the upper, right? The doctrine team are updating the base platform

Comment by Ciro Vargas [ 19/Mar/15 ]

Benjamin Eberlei yes, i can do. Or mapping hardcoded

Comment by Ciro Vargas [ 19/Mar/15 ]

See on https://github.com/doctrine/dbal/blob/2a9e9943f33610bfde4637abeafe00edd201803c/lib/Doctrine/DBAL/Platforms/SQLServerPlatform.php

that's works no fine, but works

the right is update for each database version, no update only for the last.

Down versions of 2012 can be bugged too

Comment by Ciro Vargas [ 23/Mar/15 ]

Solved https://gist.github.com/cirovargas/e5c0bfbc404bb414bb2b





[DBAL-1177] Cannot drop index 'site': needed in a foreign key constraint. Doctrine drops index before create Created: 18/Mar/15  Updated: 18/Mar/15

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

Type: Bug Priority: Major
Reporter: seyfer Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: dbal, migrations, schemadiff


 Description   

The problem is occurred when I generate migration for an entity on an existed database.
I'm add mapping from one table to table site. Generated migrations was like this

$this->addSql('ALTER TABLE request ADD CONSTRAINT FK_3B978F9F694309E4 FOREIGN KEY (site) REFERENCES sites (id)');
$this->addSql('DROP INDEX site ON request');
$this->addSql('CREATE INDEX IDX_3B978F9F694309E4 ON request (site)');

I'm already have index site on site column before generation migration, and migration tries, as you can see, first drop old index and than add new. But

[Doctrine\DBAL\Exception\DriverException]
An exception occurred while executing 'DROP INDEX site ON request':
SQLSTATE[HY000]: General error: 1553 Cannot drop index 'site': needed in a foreign key constraint

[Doctrine\DBAL\Driver\PDOException]
SQLSTATE[HY000]: General error: 1553 Cannot drop index 'site': needed in a foreign key constraint

If i change migration like that - all works.

$this->addSql('ALTER TABLE request ADD CONSTRAINT FK_3B978F9F694309E4 FOREIGN KEY (site) REFERENCES sites (id)');
$this->addSql('CREATE INDEX IDX_3B978F9F694309E4 ON request (site)');
$this->addSql('DROP INDEX site ON request');

I think migration should drop old or duplicate indexes AFTER adding new, not before.



 Comments   
Comment by mikeSimonson [ 18/Mar/15 ]

Wouldn't it make more sense not to touch the index at all ?

Comment by seyfer [ 18/Mar/15 ]

It generates automatically as is. I don't know why it tries add another index and drop mine. As I said - I add mapping on already existed table with index added by hand.
When I added a mapping - I need generate migration to sync my mapping and database. And it generates this migration.





[DBAL-1176] [GH-819] Added support for inline comments for SQLite Created: 18/Mar/15  Updated: 18/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 hason:

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

Message:






[DBAL-1175] [GH-818] Rebuild SQLServerPlatform::doModifyLimitQuery again to use a CTE Created: 17/Mar/15  Updated: 17/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 zeroedin-bill:

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

Message:

Also only uses 1 regex.

This method is vastly simpler and more reliable than the old method of parsing a whole lot of stuff.

A caveat: if a query is passed that contains a subquery with an ORDER BY clause, the inner ORDER BY clause will be dropped. SQL server doesn't support using ORDER BY inside subqueries. In the future I think we should consider throwing an exception when these are found.

For now, hold off on merging this. There is a PR open for the ORM Paginator that prevents it from sending queries with multiple ORDER BY clauses. The Paginator is the only place in the ORM where this occurs. Until that PR is merged, this one should probably stay open.

I'll be adding a set of functional tests for the Paginator later this week.






[DBAL-1174] [GH-817] Fixed a minor typo Created: 16/Mar/15  Updated: 16/Mar/15  Resolved: 16/Mar/15

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

Type: Documentation Priority: Minor
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: documentation, memory, sqlite, typo


 Description   

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

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

Message:



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

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

Comment by Doctrine Bot [ 16/Mar/15 ]

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





[DBAL-1173] MySQL schema-tool:update fails if there are two tables with the same name (lower and uppercase) Created: 16/Mar/15  Updated: 16/Mar/15

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

Type: Bug Priority: Major
Reporter: Andrzej Marcinkowski Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

ubuntu 14.04
php 5.5.12
mysql 5.6.19



 Description   

Hi,

when performing:
vendor/bin/doctrine orm:schema-tool:update --force --dump-sql

I get:

[RuntimeException]
Error Output:
[Doctrine\DBAL\Schema\SchemaException]
The table with name 'hospital.user_roles' already exists.

I have 2 tables with names USER_ROLES and user_roles in database, which are unrelated to the updated schema. They just exist in the db.

After deletion of one of them schema update works well.

Regards,
Andrzej






[DBAL-1172] [GH-816] Fix uses Statement::setFetchMode function in class Connection Created: 13/Mar/15  Updated: 15/Mar/15  Resolved: 15/Mar/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: Won't Fix Votes: 0
Labels: fetch, fetch-mode, pdo


 Description   

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

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

Message:

I have a problem because interface function Connection::setFetchMode doesnt match PDOStatement::setFetchMode. Through Connection::setFetchMode I can send only first param to function PDOStatement::setFetchMode.
With this fix in Connection class, function Statement::setFetchMode used with call_user_func_array and this allow send more than one argument.
With this fix, I can use native PDO::FETCH_COLUMN like this:
$conn = $this->get('database_connection');
$conn->setFetchMode(\PDO::FETCH_COLUMN, 0);
$result = $conn->fetchAll("SELECT ..........");
and get full result array.
With function Connection::fetchColumn, I can take only the first row in result array.



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

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





[DBAL-1171] QueryBuilder - getForUpdateSQL Created: 13/Mar/15  Updated: 13/Mar/15  Resolved: 13/Mar/15

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

Type: Improvement Priority: Minor
Reporter: Bojidar Hristov Assignee: Marco Pivetta
Resolution: Can't Fix Votes: 0
Labels: QueryBuilder, lockhints


 Description   

It would be nice to be able to append FOR UPDATE in QueryBuilder.
Right now this is my workaround:

$qb = $connection->createQueryBuilder();
.......... qb stuffs .............
$stmt = $connection->executeQuery($qb->getSQL() . ' FOR UPDATE', $qb->getParameters());



 Comments   
Comment by Marco Pivetta [ 13/Mar/15 ]

This cannot be implemented, as FOR UPDATE is not cross-RDBMS compatible syntax.

Comment by Bojidar Hristov [ 13/Mar/15 ]

ORM supports it thru `$this->platform->getWriteLockSQL();`

Why DBAL not?

Comment by Marco Pivetta [ 13/Mar/15 ]

It's an implementation detail: each platform gets its own correct SQL generated. If you need platform-specific SQL, then don't use the query builder.





[DBAL-1170] self-referential column fails with sqlite and InheritanceType("JOINED") Created: 11/Mar/15  Updated: 11/Mar/15

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

Type: Bug Priority: Major
Reporter: Jeff Warnica Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Per summary, if I have a base abstract class with a property referencing its own ID, and InheritanceType("JOINED"), the generated sqlite DDL will cause runtime constraint errors.

trimmed down example of what I'm doing, seeing

/**
 * @Entity
 * @InheritanceType("JOINED")
 * @DiscriminatorColumn(name="discr", type="string")
 */
    
abstract class GraphElement  {
    /**
     * @Id 
     * @Column(type="integer")
     * @GeneratedValue(strategy="AUTO")
     * @var int
     * */
    public $id;
            
    /**
     * @OneToOne(targetEntity="GraphElement")
     * @JoinColumn(name="owningProcessDefinition_id", referencedColumnName="id")
     * @var ProcessDefinition
     */
    protected $processDefinition = null;
......
}
/** @Entity **/
class ProcessDefinition extends GraphElement {}

Generates:
CREATE TABLE GraphElement (id INTEGER NOT NULL, name VARCHAR(255) NOT NULL, owningProcessDefinition_id INTEGER DEFAULT NULL, discr VARCHAR(255) NOT NULL, PRIMARY KEY(id), CONSTRAINT FK_4779DC6C1693DAAD FOREIGN KEY (owningProcessDefinition_id) REFERENCES GraphElement (id) NOT DEFERRABLE INITIALLY IMMEDIATE)

and then:

2015-03-11T15:46:15+00:00 [sql] "START TRANSACTION"
2015-03-11T15:46:15+00:00 [sql] INSERT INTO GraphElement (name, owningProcessDefinition_id, discr) VALUES (?, ?, ?)
2015-03-11T15:46:15+00:00 [sql] INSERT INTO ProcessDefinition (id, startState_id) VALUES (?, ?)
.....
2015-03-11T15:46:15+00:00 [sql] INSERT INTO GraphElement (name, owningProcessDefinition_id, discr) VALUES (?, ?, ?)
....
2015-03-11T15:46:15+00:00 [sql] UPDATE GraphElement SET owningProcessDefinition_id = ? WHERE id = ?
2015-03-11T15:46:15+00:00 [sql] "ROLLBACK"

will ultimately give:

Doctrine\DBAL\Exception\UniqueConstraintViolationException: An exception occurred while executing 'UPDATE GraphElement SET owningProcessDefinition_id = ? WHERE id = ?' with params [1, 1]:
SQLSTATE[23000]: Integrity constraint violation: 19 UNIQUE constraint failed: GraphElement.owningProcessDefinition_id' in /home/jwarnica/workspace/azBPM/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/AbstractSQLiteDriver.php:48

because of that "NOT DEFERRABLE INITIALLY IMMEDIATE"

Note: Everything just works with @InheritanceType("SINGLE_TABLE")

It does look like SqlitePlatform.php has the ability to not create this constraint, but I wasn't able to find any documentation on how (or if possible) to apply (loosen) FK constraints.

In any case, if SINGLE_TABLE just works, JOINED should trigger the right (no) constraints on self-referential OneToOne. Or at least have what one needs to do documented.






[DBAL-1169] [GH-815] Fix for inconsistent use of getSQLDeclaration Created: 11/Mar/15  Updated: 13/Mar/15  Resolved: 13/Mar/15

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

Type: Bug Priority: Minor
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: case-sensitivity, type, typo


 Description   

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

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

Message:

I found an inconsistency in naming of the getSQLDeclaration method
I changed in 5 files `getSqlDeclaration` -> `getSQLDeclaration`



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

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

Comment by Doctrine Bot [ 13/Mar/15 ]

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





[DBAL-1168] Schema's getMigrateFromSql always adds CREATE SCHEMA Created: 11/Mar/15  Updated: 28/May/15

Status: Open
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: Varga Bence Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: postgresql, schematool
Environment:

Postgresql



 Description   

I originally posted this to Migrations; noticing that all the generated down() methods start with a "CREATE SCHEMA public" line.

Inspecting the return from Schema#getMigrateFromSql it indeed contains the create statement.



 Comments   
Comment by Adam Sentner [ 19/May/15 ]

I am also having this issue. The down() method always adds: $this->addSql('CREATE SCHEMA public');

Same environment, also using Postgres.

Any chance this is on anyone's radar for a release in the near future?

Comment by Albert Casademont [ 28/May/15 ]

Hit by this too. The problem seems to be that the "public" namespace is not added to the table names by default and hence the diff between what postgres says (a "public" schema is created by default in the DB) and what our schema says.

I tried to solve this with a workaround by prepending "public." to all table names. It works for the first migration but then in the next migration will try to delete all tables without the "public." and create them again. So that's not working!

The solution is assuming that there's always a default 'public' namespace in the Schema.php class.





[DBAL-1167] [GH-814] allow serverVersion to be unspecified Created: 09/Mar/15  Updated: 09/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: 1
Labels: None


 Description   

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

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

Message:

Hi,

this PR allows `serverVersion`to be nullable.

We use doctrine/dbal in Integration-Tests and to prevent the unit-tests from connecting to a database, we specify `serverVersion` with something made-up (like `5.6`).

However, i'm not comfortable set `serverVersion` to a made-up server-version to prevent connections from being made, when there even isn't a server to connect to. With this PR merged, we could specify `serverVersion` to be `null` instead of something like `5.6` and still prevent connections from being made. `null` is a valid return value for `getDatabasePlatformVersion()`.






[DBAL-1166] [GH-813] Treat SQLite Connection URLs Differently in DriverManager Created: 07/Mar/15  Updated: 07/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 chrisguitarguy:

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

Message:

In addition to setting `dbname`, which is ignored by the SQLite Driver, set the
`path` and `memory` params based on the database URL.

See DBAL-1164






[DBAL-1165] [GH-812] Treat SQLite Connection URLs Differently in DriverManager Created: 07/Mar/15  Updated: 07/Mar/15  Resolved: 07/Mar/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: drivermanager, sqlite


 Description   

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

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

Message:

In addition to setting `dbname`, which is ignored by the SQLite Driver, set the
`path` and `memory` params based on the database URL.

See http://www.doctrine-project.org/jira/browse/DBAL-1164

Not sure if this is a good solution, but it seemed more okay (less risky to BC) than changing the driver itself.



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

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





[DBAL-1164] Creating SQLite Connections via a URL Does Not Work Created: 07/Mar/15  Updated: 07/Mar/15

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

Type: Bug Priority: Minor
Reporter: Christopher Davis Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

When creating a SQL light connection put the URL path into the `dbname` param. But the SQLite driver doesn't using the `dbname` param: it uses the `path` parameter.

So doing this:

$conn = DriverManager::getConnection([
'url' => 'sqlite:////some/path/here',
]);

Generates a PDO DSN like this: `sqlite:`. The path is completely ignored.

See the driver code here: https://github.com/doctrine/dbal/blob/6b6143ba16e5f17242835910173c033a8f73f845/lib/Doctrine/DBAL/Driver/PDOSqlite/Driver.php#L81-L88

`DriverManager` either needs some logic to use the path when it sees a sqlite URL or the Driver itself should use `dbname` (eg. check path, check dbname, check memory).



 Comments   
Comment by Christopher Davis [ 07/Mar/15 ]

Same is true for memory databases. `dbname` is set, but the driver never checks it.





[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: 13/May/15  Resolved: 13/May/15

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

Type: Bug Priority: Minor
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Invalid Votes: 0
Labels: allow_url_fopen, blob-type, types


 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.



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

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





[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: 30/Apr/15  Resolved: 30/Apr/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: composer, symfony


 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



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

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





[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: 16/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 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.



 Comments   
Comment by Davi Koscianski Vidal [ 16/Mar/15 ]

Hi, any thoughts on this?





[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: 13/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 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.



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

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





[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