[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: 31/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/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
```






[DBAL-1186] [GH-826] fix incorrect ordering of columns in clustered indexes on sql server Created: 31/Mar/15  Updated: 31/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/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.






[DBAL-1185] [GH-825] Add postgresql 9.4 for travis builds Created: 30/Mar/15  Updated: 30/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/825

Message:






[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.






Generated at Thu Apr 02 04:25:44 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.