[DBAL-842] [GH-548] DBAL-774 - added failing test for parsing order of joins Created: 21/Mar/14  Updated: 17/Sep/14  Resolved: 17/Sep/14

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

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

Issue Links:
Reference
relates to DBAL-774 DBAL parses joins in wrong order Resolved
is referenced by DBAL-991 [GH-679] [DBAL-774] Fix QueryBuilder ... Resolved

 Description   

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

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

Message:

I had finaly some time to investigate the problem a bit more, and the problem is the way doctrine/dbal >= 2.4 handles the parsing of joins

The expected result is the way doctrine/dbal 2.3 handles the joins, which is not quite the way i expect that the query would be outputted but it is correct for execution.



 Comments   
Comment by Jeroen Thora [ 21/Mar/14 ]

Pullrequest related to DBAL-774

Comment by Doctrine Bot [ 17/Sep/14 ]

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

Comment by Doctrine Bot [ 17/Sep/14 ]

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

Comment by Doctrine Bot [ 17/Sep/14 ]

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





[DBAL-774] DBAL parses joins in wrong order Created: 08/Jan/14  Updated: 17/Sep/14  Resolved: 17/Sep/14

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: 2.4, 2.5, 2.4.1, 2.4.2
Fix Version/s: 2.5
Security Level: All

Type: Bug Priority: Critical
Reporter: Jeroen Thora Assignee: Marco Pivetta
Resolution: Fixed Votes: 1
Labels: querybuilder

Issue Links:
Reference
is referenced by DBAL-842 [GH-548] DBAL-774 - added failing tes... Resolved
is referenced by DBAL-991 [GH-679] [DBAL-774] Fix QueryBuilder ... Resolved

 Description   

I have a problem that doctrine dbal orders the joins in a wrong order if you use more complex join combinations (worked fine in DBAL 2.3)

Dbal Querybuilder:

        $qb->select('tbl_profile_additional_property.pkid AS pkid')
        ->from('tbl_profile_additional_property', 'tbl_profile_additional_property')
        ->leftjoin('tbl_profile_additional_property', 'tbl_rating_system', 'tbl_rating_system', 'tbl_profile_additional_property.fk_rs = tbl_rating_system.pkid')
        ->leftjoin('tbl_rating_system', 'tbl_rating_system_translation', 'tbl_rating_system_translation', 'tbl_rating_system_translation.fk_rs = tbl_rating_system.pkid AND tbl_rating_system_translation.fk_language = :languageid')
        ->leftjoin('tbl_profile_additional_property', 'tbl_score_level', 'tbl_score_level', 'tbl_profile_additional_property.fk_scoregoal = tbl_score_level.pkid')
        ->leftjoin('tbl_rating_system_translation', 'tbl_score_level_translation', 'tbl_score_level_translation', 'tbl_score_level_translation.fk_rs_translation = tbl_rating_system_translation.pkid AND tbl_score_level_translation.fk_sl = tbl_score_level.pkid')
        ->where('tbl_profile_additional_property.fk_function = :functionid')
        ->setParameter('functionid', $functionId)
        ->setParameter('languageid', $languageId);

Expected Query:

SELECT 
tbl_profile_additional_property.pkid AS pkid 
FROM tbl_profile_additional_property tbl_profile_additional_property 
LEFT JOIN tbl_rating_system tbl_rating_system ON tbl_profile_additional_property.fk_rs = tbl_rating_system.pkid 
LEFT JOIN tbl_rating_system_translation tbl_rating_system_translation ON tbl_rating_system_translation.fk_rs = tbl_rating_system.pkid AND tbl_rating_system_translation.fk_language = :languageid 
LEFT JOIN tbl_score_level tbl_score_level ON tbl_profile_additional_property.fk_scoregoal = tbl_score_level.pkid 
LEFT JOIN tbl_score_level_translation tbl_score_level_translation ON tbl_score_level_translation.fk_rs_translation = tbl_rating_system_translation.pkid AND tbl_score_level_translation.fk_sl = tbl_score_level.pkid 
WHERE tbl_profile_additional_property.fk_function = :functionid

Resulted Query:

SELECT 
tbl_profile_additional_property.pkid AS pkid 
FROM tbl_profile_additional_property tbl_profile_additional_property 
LEFT JOIN tbl_rating_system tbl_rating_system ON tbl_profile_additional_property.fk_rs = tbl_rating_system.pkid 
LEFT JOIN tbl_rating_system_translation tbl_rating_system_translation ON tbl_rating_system_translation.fk_rs = tbl_rating_system.pkid AND tbl_rating_system_translation.fk_language = :languageid 
LEFT JOIN tbl_score_level_translation tbl_score_level_translation ON tbl_score_level_translation.fk_rs_translation = tbl_rating_system_translation.pkid AND tbl_score_level_translation.fk_sl = tbl_score_level.pkid 
LEFT JOIN tbl_score_level tbl_score_level ON tbl_profile_additional_property.fk_scoregoal = tbl_score_level.pkid 
WHERE tbl_profile_additional_property.fk_function = :functionid

(The last 2 LEFT JOINS of the query are the problem)

The problem is with getSQLForJoins it loops over all the joins and foreach join it follows all the used joins aliases until the deepest point. Therefor it will parse this join first

->leftjoin('tbl_rating_system_translation', 'tbl_score_level_translation', 'tbl_score_level_translation', 'tbl_score_level_translation.fk_rs_translation = tbl_rating_system_translation.pkid AND tbl_score_level_translation.fk_sl = tbl_score_level.pkid')

Before it generates the sql for this line (this line is needed becaus the line above needs a join on tbl_score_level first)

->leftjoin('tbl_profile_additional_property', 'tbl_score_level', 'tbl_score_level', 'tbl_profile_additional_property.fk_scoregoal = tbl_score_level.pkid')

The order the querybuilder in php is build (select, from, joins, etc) is the order it should be parsed as sql.

Ps. I have added 2.5 also as affectsversion because the code didn't change as far is i know



 Comments   
Comment by Chesley Brown [ 22/Jan/14 ]

Noticing this issue with v2.4 as well. However, I'm also noticing the leftJoins being ordered incorrectly on v2.3.3 as well... however the ordering between the two versions are not the same. They are both just ordered differently than the order that I actually call the leftJoin methods in.

Comment by Jeroen Thora [ 21/Mar/14 ]

I have added a failing test for this problem in doctrine/dbal#548

Comment by Doctrine Bot [ 17/Sep/14 ]

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

Comment by Marco Pivetta [ 17/Sep/14 ]

Resolved in DBAL-991 - won't be backported in 2.4 as 2.4 behavior could radically change otherwise.





[DBAL-991] [GH-679] [DBAL-774] Fix QueryBuilder parsing order of joins Created: 17/Sep/14  Updated: 17/Sep/14  Resolved: 17/Sep/14

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

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

Issue Links:
Reference
relates to DBAL-774 DBAL parses joins in wrong order Resolved
relates to DBAL-842 [GH-548] DBAL-774 - added failing tes... Resolved

 Description   

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

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

Message:

This is a fix for DBAL-774(http://www.doctrine-project.org/jira/browse/DBAL-774) and is the followup for PR #548.



 Comments   
Comment by Doctrine Bot [ 17/Sep/14 ]

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

Comment by Doctrine Bot [ 17/Sep/14 ]

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

Comment by Doctrine Bot [ 17/Sep/14 ]

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





[DBAL-989] Tag new version for 2.3.x Created: 15/Sep/14  Updated: 17/Sep/14  Resolved: 15/Sep/14

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

Type: Task Priority: Major
Reporter: Jeroen Thora Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: None


 Description   

Hi,

Would it be possible to release a new version of doctrine 2.3.x? I stumbled into this issue DBAL-522 and there was a fix (and merged in 2.3 branch). Don't know if you still support the 2.3 version, but there were some fixes done which are not included in a tag/release. See 2.3.4...2.3 diff

In the 2.4 branch (releases) this is fixed but because of issue DBAL-774 i'm unable to upgrade to 2.4

Thanks



 Comments   
Comment by Marco Pivetta [ 15/Sep/14 ]

A new 2.3.x should be viable: can you backport the patch into a PR targeted at the 2.3 branch?

Comment by Jeroen Thora [ 15/Sep/14 ]

The fix for this issue was already backported into the 2.3 branch, but it wasn't included in any release so far. But I just saw that deeky released a new 2.3.5 version, so as far as i can see now, this should be fixed. But will confirm tomorrow!

Comment by Steve Müller [ 15/Sep/14 ]

Jeroen Thora yes, released 2.3.5 today. Blog post will follow later.

Comment by Doctrine Bot [ 17/Sep/14 ]

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

Comment by Doctrine Bot [ 17/Sep/14 ]

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

Comment by Doctrine Bot [ 17/Sep/14 ]

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





[DBAL-990] [GH-678] Clean up unused uses Created: 17/Sep/14  Updated: 17/Sep/14  Resolved: 17/Sep/14

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

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


 Description   

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

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

Message:

Getting rid of unused `use` statements



 Comments   
Comment by Doctrine Bot [ 17/Sep/14 ]

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

Comment by Doctrine Bot [ 17/Sep/14 ]

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





[DBAL-552] Colon (":") in field name treats like query parameter Created: 25/Jun/13  Updated: 15/Sep/14  Resolved: 29/Dec/13

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

Type: Bug Priority: Major
Reporter: Daniel Bojdo Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: None
Environment:

MySQL


Issue Links:
Reference
is referenced by DBAL-624 Parameter in comments is parsed Open

 Description   

The colon sign (":") is permitted for columns' name but Doctrine treats them like parameters placeholder:

SELECT `d.ns:col_name` FROM my_table d WHERE `d.date` >= :param1

causes DBALException:

An exception occurred while executing 'SELECT `d.ns:col_name` FROM my_table d WHERE `d.date` >= :param1' with params ["2013-06-24 14:22:18"]: Value for :col_name not found in params array. Params array key should be "col_name"


 Comments   
Comment by Benjamin Eberlei [ 25/Jun/13 ]

does this work with plain PDO?

Comment by Daniel Bojdo [ 25/Jun/13 ]

Yes, it works perfectly fine with PDO. It also works properly with Doctrine\DBAL\Connection.
I suppose there's a bug somewhere in QueryBuilder.

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

Patch supplied in PR: https://github.com/doctrine/dbal/pull/477

Comment by Doctrine Bot [ 29/Dec/13 ]

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





[DBAL-766] PostgreSQL: Fix statement for getTableWhereClause method Created: 05/Jan/14  Updated: 15/Sep/14  Resolved: 05/Jan/14

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

Type: Bug Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

https://github.com/doctrine/dbal/pull/492






[DBAL-760] [GH-490] Don't return warnings as errors in sqlsrv driver Created: 03/Jan/14  Updated: 15/Sep/14  Resolved: 03/Jan/14

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

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


 Description   

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

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

Message:

The SQL Server platforms use `sp_rename` stored procedure for renaming schema objects like tables, indexes or columns. SQL Server raises a warning when invoking this stored procedure, although the result is as expected:

```php
Doctrine\DBAL\Driver\SQLSrv\SQLSrvException: SQLSTATE [01000, 15477]: [Microsoft][SQL Server Native Client 11.0][SQL Server]Vorsicht: Wenn Sie Teile eines Objektnamens ��ndern, werden Skripts und gespeicherte Prozeduren m��glicherweise funktionsunf��hig.
```

This PR configures the sqlsrv driver not to handle warnings returned from the server as errors to prevent this. The PDO_SQLSRV driver silences warnings, too.



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

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





[DBAL-741] [GH-474] Fix foreign key columns order in Oracle Created: 28/Dec/13  Updated: 15/Sep/14  Resolved: 29/Dec/13

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

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


 Description   

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

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

Message:

The order of columns in foreign key constraints is not synchronized by the Oracle platform.

*Failing test:*
```bash
Doctrine\Tests\DBAL\Functional\Schema\OracleSchemaManagerTest::testListForeignKeysComposite
Failed asserting that two arrays are equal.
— Expected
+++ Actual
@@ @@
Array (

  • 0 => 'id'
  • 1 => 'foreign_key_test'
    + 0 => 'foreign_key_test'
    + 1 => 'id'
    )

/home/deeky/dev/doctrine/dbal/tests/Doctrine/Tests/DBAL/Functional/Schema/SchemaManagerFunctionalTestCase.php:672
```



 Comments   
Comment by Doctrine Bot [ 29/Dec/13 ]

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





[DBAL-742] [GH-475] Fix column default value introspection in Oracle Created: 28/Dec/13  Updated: 15/Sep/14  Resolved: 29/Dec/13

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

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


 Description   

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

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

Message:

A bug in `OracleSchemaManager` cause a column's default value always to be null. Besides that default values are enclosed in single quotes when retrieved from database which is not evaluated by the schema manager, either.
This PR also fixes the default value tests in Oracle's functional test suite.



 Comments   
Comment by Doctrine Bot [ 29/Dec/13 ]

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





[DBAL-589] Doctrine\DBAL\Schema\Column::visit has an Invalid Type Hint Created: 27/Aug/13  Updated: 15/Sep/14  Resolved: 21/Nov/13

Status: Resolved
Project: Doctrine DBAL
Component/s: Schema Managers
Affects Version/s: 2.3.4
Fix Version/s: 2.3.5

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

$ php -v
PHP 5.4.15 (cli) (built: Aug 16 2013 15:38:16)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies
with Xdebug v2.2.1, Copyright (c) 2002-2012, by Derick Rethans

$ uname -a
Darwin chrispmg.local 11.4.2 Darwin Kernel Version 11.4.2: Thu Aug 23 16:25:48 PDT 2012; root:xnu-1699.32.7~1/RELEASE_X86_64 x86_64



 Description   

Column::visit typehints against a class that doesn't exist (`Doctrine\DBAL\Schema\Visitor`).

https://github.com/doctrine/dbal/blob/2.3/lib/Doctrine/DBAL/Schema/Column.php#L398

Looks like there's a `use` statement at the top of the file that imports the correct class: https://github.com/doctrine/dbal/blob/2.3/lib/Doctrine/DBAL/Schema/Column.php#L23






[DBAL-613] [GH-377] Fixed logic error in Sharding component Created: 24/Sep/13  Updated: 15/Sep/14  Resolved: 26/Sep/13

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: 2.3, 2.4
Fix Version/s: 2.5, 2.4.1, 2.3.5
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: sharding


 Description   

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

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

Message:

No need to choose shard by chooser, as is pass the identifiers shard.



 Comments   
Comment by Doctrine Bot [ 26/Sep/13 ]

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





[DBAL-522] BC break : executeQuery with an array containing null value(s). Created: 20/May/13  Updated: 15/Sep/14  Resolved: 21/May/13

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: 2.3.4
Fix Version/s: 2.4, 2.3.5

Type: Bug Priority: Blocker
Reporter: lemeunier Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: dbal
Environment:

Mac OSX 10.8.3, Mysql 5.5.28, PHP5.4



 Description   

Hello, i have got an error with doctrine 2.3.4 when i try to run the following code :

 
    $conn->executeQuery(
        'INSERT INTO FOO (foo, bar) values (:foo, :bar)', 
         array('foo' => 1, 'bar' => null)
     );

Error : Value for :bar not found in params array. Params array key should be "bar"

This code worked with doctrine 2.3.3.

I think the error comes from the function 'extractParam' in SQLParserUtils.php (DBAL)

line 215 : if (isset($paramsOrTypes[$paramName]))

The key exists even if the value is null.
So it should be:

  if (array_key_exists($paramName, $paramsOrTypes)) 

I am not enough confident to try a PR.
Thanks in advance!



 Comments   
Comment by Marco Pivetta [ 20/May/13 ]

I suggested a hotfix at https://github.com/doctrine/dbal/pull/322

Comment by lemeunier [ 21/May/13 ]

Thanks for the hotfix.





[DBAL-988] [GH-677] avoid recursive quoteIdentifier call Created: 11/Sep/14  Updated: 12/Sep/14  Resolved: 12/Sep/14

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

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


 Description   

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

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

Message:

each $part does not contain ".", so quoteSingleIdentifier may be called directly thus avoiding recursive strpos checks.



 Comments   
Comment by Steve Müller [ 12/Sep/14 ]

Fixed in commit: https://github.com/doctrine/dbal/commit/0d99f152573c2da1a4884cc90a9fdfc038f47f7b





[DBAL-816] [GH-529] fix for postres listTableNames Created: 18/Feb/14  Updated: 11/Sep/14  Resolved: 11/Sep/14

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

Type: Bug Priority: Major
Reporter: 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 MaksSlesarenko:

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

Message:

fix for listTableNames to return unescaped table names



 Comments   
Comment by Doctrine Bot [ 11/Sep/14 ]

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

Comment by Doctrine Bot [ 11/Sep/14 ]

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





[DBAL-987] [GH-675] [DBAL-959] Allow to get bound parameter types from query builder Created: 11/Sep/14  Updated: 11/Sep/14  Resolved: 11/Sep/14

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

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

Issue Links:
Dependency
is required for DBAL-959 [GH-648] Allow to get bound parameter... Resolved

 Description   

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

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

Message:

Replaces https://github.com/doctrine/dbal/pull/648.

Added tests.



 Comments   
Comment by Doctrine Bot [ 11/Sep/14 ]

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

Comment by Doctrine Bot [ 11/Sep/14 ]

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

Comment by Doctrine Bot [ 11/Sep/14 ]

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

Comment by Doctrine Bot [ 11/Sep/14 ]

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





[DBAL-449] [GH-274] Support column charset/collation on capable platforms Created: 19/Feb/13  Updated: 11/Sep/14  Resolved: 11/Sep/14

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

Type: Improvement Priority: Major
Reporter: Benjamin Eberlei Assignee: Steve Müller
Resolution: Incomplete Votes: 0
Labels: None


 Description   

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

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

Message:

Basically the same feature wanted as in #245



 Comments   
Comment by Doctrine Bot [ 11/Sep/14 ]

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

Comment by Doctrine Bot [ 11/Sep/14 ]

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





[DBAL-647] MySqlPlatform's getCollationFieldDeclaration() looks like it has the wrong name Created: 01/Nov/13  Updated: 11/Sep/14  Resolved: 26/Nov/13

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

Type: Bug Priority: Major
Reporter: John Flatness Assignee: Benjamin Eberlei
Resolution: Duplicate Votes: 0
Labels: None


 Description   

The MySqlPlatform has a method getCollationFieldDeclaration(). As far as I can tell, that method's not actually used for anything.

However, looking at the other Platforms and the AbstractPlatform, it looks like this method is what is elsewhere called getColumnCollationDeclarationSQL().

The AbstractPlatform calls getColumnCollationDeclarationSQL() when getting the SQL for a column with a "collation" set; for MySQL, this currently causes no effect since the default, blank implementation from the AbstractPlatform is being used.

It looks like the name of this method should be changed.



 Comments   
Comment by John Flatness [ 05/Nov/13 ]

The current name of the method looks like it dates back to the initial refactorings for Doctrine 2. No other methods there still use the "Field" terminology in the method name, and all the others that return snippets of SQL uniformly use "DeclarationSQL" instead of just "Declaration".

That combined with the different name for seemingly the same method in the AbstractPlatform and SQLServerPlatform makes it seem like this one just got left behind.

Comment by Steve Müller [ 25/Nov/13 ]

The reason for this diverge in implementation and terminology is that there still is an open PR that enables support for column collation declaration on capable platforms which is not yet merged:

https://github.com/doctrine/dbal/pull/274

and

https://github.com/doctrine/dbal/pull/245

Partial support for SQL Server has already been merged in:

https://github.com/doctrine/dbal/pull/282

This feature is nearly finished and about to be merged. AbstractPlatform::getCollationFieldDeclaration() will be deprecated then to ensure BC. Does that answer your question? =) If so, can this ticket be closed?

Comment by John Flatness [ 26/Nov/13 ]

I believe that does answer my question.

One little thing: when you say AbstractPlatform::getCollationFieldDeclaration() will be deprecated, you mean the one on MysqlPlatform, right? I believe there is no such method on the AbstractPlatform.

Comment by Steve Müller [ 26/Nov/13 ]

Yes it will be deprecated in MySQLPlatform. See the PR.
Can you tell me what is still unclear? Or what you'd expect of this ticket?

Comment by John Flatness [ 26/Nov/13 ]

Okay, then I think it was just a typo in your first comment.

PR #245 on Github seems like it covers this squarely, so I suppose this issue doesn't stand for much on its own.

Comment by Steve Müller [ 26/Nov/13 ]

You are right it was not supposed to be AbstractPlatform but MySQLPlatform

Comment by Doctrine Bot [ 11/Feb/14 ]

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

Comment by Doctrine Bot [ 11/Sep/14 ]

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

Comment by Doctrine Bot [ 11/Sep/14 ]

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





[DBAL-978] [GH-665] convenience method for FULL OUTER JOINs in QueryBuilder Created: 21/Aug/14  Updated: 11/Sep/14  Resolved: 11/Sep/14

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

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

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

Message:

was working on a project today where I needed a full outer join and found out that the method was missing in the QueryBuilder.
It's a minor change and I have also included a test case.

david



 Comments   
Comment by Doctrine Bot [ 11/Sep/14 ]

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





[DBAL-831] [GH-540] unit test to create constraint on forced lowercase table in oracle Created: 04/Mar/14  Updated: 11/Sep/14

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

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


 Description   

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

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

Message:

This might be crazy - but this was working in the 2.3.x code basis.

On master as well as 2.4.2 following error is throws:
````
Exception : [Doctrine\DBAL\Exception\TableNotFoundException] An exception occurred while executing 'DECLARE
constraints_Count NUMBER;
BEGIN
SELECT COUNT(CONSTRAINT_NAME) INTO constraints_Count FROM USER_CONSTRAINTS WHERE TABLE_NAME = '"OC_STORAGES"' AND CONSTRAINT_TYPE = 'P';
IF constraints_Count = 0 OR constraints_Count = '' THEN
EXECUTE IMMEDIATE 'ALTER TABLE "OC_STORAGES" ADD CONSTRAINT "OC_STORAGES_AI_PK" PRIMARY KEY ("NUMERIC_ID")';
END IF;
END;':

ORA-00942: table or view does not exist
ORA-06512: at line 6

With queries:
6. SQL: 'DECLARE
constraints_Count NUMBER;
BEGIN
SELECT COUNT(CONSTRAINT_NAME) INTO constraints_Count FROM USER_CONSTRAINTS WHERE TABLE_NAME = '"OC_STORAGES"' AND CONSTRAINT_TYPE = 'P';
IF constraints_Count = 0 OR constraints_Count = '' THEN
EXECUTE IMMEDIATE 'ALTER TABLE "OC_STORAGES" ADD CONSTRAINT "OC_STORAGES_AI_PK" PRIMARY KEY ("NUMERIC_ID")';
END IF;
END;' Params:
5. SQL: 'CREATE TABLE "oc_storages" ("id" VARCHAR2(64) NOT NULL, "numeric_id" NUMBER(10) NOT NULL, PRIMARY KEY("id"))' Params:
4. SQL: 'DROP TABLE "oc_storages"' Params:
3. SQL: 'DROP TRIGGER "OC_STORAGES"_AI_PK' Params:
2. SQL: 'ALTER SESSION SET NLS_TIME_FORMAT = 'HH24:MI:SS' NLS_DATE_FORMAT = 'YYYY-MM-DD HH24:MI:SS' NLS_TIMESTAMP_FORMAT = 'YYYY-MM-DD HH24:MI:SS' NLS_TIMESTAMP_TZ_FORMAT = 'YYYY-MM-DD HH24:MI:SS TZH:TZM' NLS_NUMERIC_CHARACTERS = '.,'' Params:

Trace:
/home/deepdiver/Development/ownCloud/dbal/lib/Doctrine/DBAL/DBALException.php:116
/home/deepdiver/Development/ownCloud/dbal/lib/Doctrine/DBAL/Connection.php:988
/home/deepdiver/Development/ownCloud/dbal/lib/Doctrine/DBAL/Schema/AbstractSchemaManager.php:971
/home/deepdiver/Development/ownCloud/dbal/lib/Doctrine/DBAL/Schema/AbstractSchemaManager.php:429
/home/deepdiver/Development/ownCloud/dbal/lib/Doctrine/DBAL/Schema/AbstractSchemaManager.php:569
/home/deepdiver/Development/ownCloud/dbal/tests/Doctrine/Tests/DBAL/Functional/Schema/OracleSchemaManagerTest.php:118

#0 /home/deepdiver/Development/ownCloud/dbal/vendor/phpunit/phpunit/PHPUnit/Framework/TestCase.php(946): Doctrine\Tests\DbalFunctionalTestCase->onNotSuccessfulTest(Object(Doctrine\DBAL\Exception\TableNotFoundException))
#1 /home/deepdiver/Development/ownCloud/dbal/vendor/phpunit/phpunit/PHPUnit/Framework/TestResult.php(648): PHPUnit_Framework_TestCase->runBare()
#2 /home/deepdiver/Development/ownCloud/dbal/vendor/phpunit/phpunit/PHPUnit/Framework/TestCase.php(776): PHPUnit_Framework_TestResult->run(Object(Doctrine\Tests\DBAL\Functional\Schema\OracleSchemaManagerTest))
#3 /home/deepdiver/Development/ownCloud/dbal/vendor/phpunit/phpunit/PHPUnit/Framework/TestSuite.php(775): PHPUnit_Framework_TestCase->run(Object(PHPUnit_Framework_TestResult))
#4 /home/deepdiver/Development/ownCloud/dbal/vendor/phpunit/phpunit/PHPUnit/Framework/TestSuite.php(745): PHPUnit_Framework_TestSuite->runTest(Object(Doctrine\Tests\DBAL\Functional\Schema\OracleSchemaManagerTest), Object(PHPUnit_Framework_TestResult))
#5 /home/deepdiver/Development/ownCloud/dbal/vendor/phpunit/phpunit/PHPUnit/TextUI/TestRunner.php(349): PHPUnit_Framework_TestSuite->run(Object(PHPUnit_Framework_TestResult), '/::testConstrai...', Array, Array, false)
#6 /usr/share/php/PHPUnit/TextUI/Command.php(176): PHPUnit_TextUI_TestRunner->doRun(Object(PHPUnit_Framework_TestSuite), Array)
#7 /tmp/ide-phpunit.php(268): PHPUnit_TextUI_Command->run(Array, true)
#8 /tmp/ide-phpunit.php(506): IDE_Base_PHPUnit_TextUI_Command::main()
#9

{main}

````



 Comments   
Comment by Doctrine Bot [ 11/Sep/14 ]

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

Comment by Doctrine Bot [ 11/Sep/14 ]

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





[DBAL-959] [GH-648] Allow to get bound parameter types from query builder. Created: 04/Aug/14  Updated: 11/Sep/14  Resolved: 11/Sep/14

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Duplicate Votes: 0
Labels: None

Issue Links:
Dependency
depends on DBAL-987 [GH-675] [DBAL-959] Allow to get boun... Resolved

 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 04/Aug/14 ]

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

Comment by Doctrine Bot [ 04/Aug/14 ]

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

Comment by Doctrine Bot [ 11/Sep/14 ]

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

Comment by Doctrine Bot [ 11/Sep/14 ]

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





Generated at Thu Sep 18 11:42:43 UTC 2014 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.