[DBAL-95] Interbase/Firebird support Created: 26/Feb/11  Updated: 17/Apr/15

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

Type: New Feature Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 5
Labels: None


 Description   

Implemented support for Interbase/Firebird dialects



 Comments   
Comment by Andreas Prucha [ 17/Apr/15 ]

Hi all,

I've create a driver (or two) for Firebird.

The development branch is available at

https://github.com/helicon-os/doctrine-dbal.git DBAL-95-firebird

There are two versions of the driver: One is based on the ibase-api, there other on Firebird PDO.

I'd consider the ibase-version as almost finished, the PDO-Version is rather experimental.

Just send me a comment and maybe we can merge it into the official doctrine dbal (propably just the ibase-version, not the PDO-Version - at least not as long the driver problems are not fixed)

I've tested it with FB 2.5, but not with the upcoming FB 3 or Interbase.

___________________
ibase_firebird

The Ibase-Driver passes the complete Doctrine-Testsuite.

___________________
pdo_firebird

The PDO-Version does not, and it has some limitations which may be related to Firebirds PDO interface itself:

  • BLOBs: Runs into memory leaks if BLOBs are used quite quickly
  • PDO Firebird's transaction handling is quite strange and the reason why it does not pass the testsuite.
  • Nested Transactions (Savepoints): Fails despite Firebird supports them. -
  • Turns a negative signed 32bit integer into a positive unsigned, if the client is running a 64bit-system. I fixed this with a special IntegerType Class in a project, but that's a ugly workaround.
Comment by Andreas Prucha [ 17/Apr/15 ]

One more comment:

I am not sure how to handle one firebird-specificity: Firebird does not preserve the case of identity-names and converts them all-upper, unless they are quoted. The behaviour looks quite similar to Oracle.

Currently I do not normalize names as the Oracle-driver does, which leads to the problem, that they are all-upper in the database anyway, but automatically quoted keywords are lowercase.

Which behaviour would you guys prefere:

Normalize them All-Upper if not quoted (including keywords)? This would allow case-insensitive references in queries, because Firebird handles unquoted names as all-upper.
Quote everything to preserve case: Unfortunately this would require manual quoting in every query.

Personally I do not really like this all-upper-pattern, but having to quote every identifier everywhere looks even more cumbersome, so it's propably the best to follow the behaviour of the oracle driver and assume uppercase if not quoted.

Does any platform have configuration-options? It might be a solution to let the user decide about the naming, e.g.

setNamingConvention(ALL_UPPER | PRESERVE_CASE)

BTW - Is the doctrine-dev mailinglist gone? I wanted to send this there, but it came back with an error.

Andreas





[DBAL-627] PDO Firebird support Created: 09/Oct/13  Updated: 17/Apr/15  Resolved: 17/Oct/13

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

Type: New Feature Priority: Major
Reporter: Roger Tryon Assignee: Marco Pivetta
Resolution: Duplicate Votes: 0
Labels: 2.5+, DBAL-95, firebird
Environment:

Windows, laravel 4



 Description   

Implement support for firebird 2.5+ database in Larvavel 4 using PDO Driver.



 Comments   
Comment by Marco Pivetta [ 17/Oct/13 ]

Dupe of DBAL-95

Comment by João Batista Fulgêncio [ 16/Dec/13 ]

Is there anyone working on it at this time?

Comment by Andreas Prucha [ 17/Apr/15 ]

See DBAL-95





[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-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-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-1199] [GH-837] Revert the addition of the wrong bin script Created: 15/Apr/15  Updated: 15/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 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





Generated at Tue Apr 21 05:04:25 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.