[DBAL-774] DBAL parses joins in wrong order Created: 08/Jan/14  Updated: 21/Mar/14

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

Type: Bug Priority: Critical
Reporter: Jeroen Thora Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: querybuilder


 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





[DBAL-862] [GH-563] Lower case "order by" keyword causes wrong LIMIT query on SQL Server Created: 02/Apr/14  Updated: 02/Apr/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 stchr:

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

Message:

SQLServerPlatform::modifyLimitQuery('SELECT * FROM user order by username')

(lowercase order by)
returns

SELECT * FROM (SELECT *, ROW_NUMBER() OVER (ORDER BY order) AS doctrine_rownum FROM user order by username) AS doctrine_tbl WHERE doctrine_rownum BETWEEN 1 AND 10

instead of

SELECT * FROM (SELECT *, ROW_NUMBER() OVER (ORDER BY username) AS doctrine_rownum FROM user) AS doctrine_tbl WHERE doctrine_rownum BETWEEN 1 AND 10





[DBAL-855] [GH-560] Fix DateTimeTz type compatibility on SQL Anywhere versions < 12 Created: 31/Mar/14  Updated: 31/Mar/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 deeky666:

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

Message:

SQL Anywhere versions < 12 do not support a native date time with timezone type. Therefore the fallback strategy is to use the normal date time type. However the format of the date time tz type declaration has to correspond to the normal date time type declaration, too then.

`getDateTimeTzTypeDeclarationSQL()` -> `getDateTimeTypeDeclarationSQL()`
`getDateTimeTzFormatString()` -> `getDateTimeFormatString()`

I thought about changing that in the `AbstractPlatform` but I am not sure if that might break assumptions in userland code and therefore BC. So I left the implementation SQL Anywhere specific.






[DBAL-856] [GH-561] Fix FOR UPDATE SQL on SQL Anywhere Created: 31/Mar/14  Updated: 31/Mar/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 deeky666:

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

Message:

It looks like there was a misunderstanding on SQL Anywhere with the `FOR UPDATE` SQL as this is actually a statement used in prepared statements and does not work the ANSI way in ORM. So I removed it in favour of the table lock hint implementation which works out quite well and makes the `getForUpdateSQL()` rather useless anyways. SQL Server does it like this, too btw and both dialects are pretty similar because SQL Anywhere once drived from it.






[DBAL-850] [GH-555] Improved performance of BlobType Created: 27/Mar/14  Updated: 27/Mar/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 BenMorel:

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

Message:

I noticed that the `string` to `resource` conversion code in `BlobType` uses a quite inefficient technique.
This PR improves its performance with a simple change involving the `php://temp` stream.

Quick benchmark of the two approaches, converting a 10MB string:

$value = str_repeat('x', 10 * 1024 * 1024);

$t = microtime(true);
$fp = fopen('data://text/plain;base64,' . base64_encode($value), 'r');
printf("%.3fs\n", microtime(true) - $t);

$t = microtime(true);
$fp = fopen('php://temp', 'rb+');
fwrite($fp, $value);
fseek($fp, 0);
printf("%.3fs\n", microtime(true) - $t);

Results on my laptop:

0.090s
0.008s

A tenfold improvement!






[DBAL-853] [GH-558] Fix integer 0 default value reverse engineering on SQL Anywhere Created: 31/Mar/14  Updated: 31/Mar/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 deeky666:

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

Message:

If an integer column was created with a default value of `0`, SQL Anywhere reverse engineers the default value to `null`. This is fixed by this PR.






[DBAL-842] [GH-548] DBAL-774 - added failing test for parsing order of joins Created: 21/Mar/14  Updated: 21/Mar/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 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





[DBAL-844] [GH-549] Fix truncate on MySQL >= 5.5 Created: 22/Mar/14  Updated: 22/Mar/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 ddeboer:

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

Message:

When truncating tables on MySQL >= 5.5, an error is thrown:

```mysql
SQLSTATE[42000]: Syntax error or access violation:
1701 Cannot truncate a table referenced in a foreign key constraint ...
```

It turns out that with MySQL 5.5.7, `TRUNCATE` behaviour has changed. From the [MySQL docs](http://dev.mysql.com/doc/refman/5.5/en/truncate-table.html):

> TRUNCATE TABLE fails for an InnoDB table if there are any FOREIGN KEY constraints from other tables that reference the table. Foreign key constraints between columns of the same table are permitted.

With this PR foreign key checks are disabled just before and re-enabled just after truncate.

As I encountered this issue using doctrine/data-fixtures, I originally submitted a fix there: https://github.com/doctrine/data-fixtures/pull/127. However, as @deeky666 pointed out, the DBAL is a better place for the fix.






[DBAL-846] [GH-551] Foreign key checks on MySQL >= 5.5.7 for TRUNCATE Created: 24/Mar/14  Updated: 24/Mar/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 tPl0ch:

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

Message:

  • Added `ConfigurablePlatform` interface to set the connection
    parameters to the Platform
  • Connection is now setting the parameters to the Platform if it
    implements `ConfigurablePlatform`
  • `MySQLPlatform::getTruncateSql()` now checks for a new param
    `disable_fk_checks`, if it is true and the version is affected, it
    automatically adds the required SQL.

Additional solution to https://github.com/doctrine/dbal/pull/549






[DBAL-848] [GH-553] [DBAL-843] Fix reverse engineering LOB type column types in MySQL Created: 25/Mar/14  Updated: 25/Mar/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 deeky666:

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

Message:

This PR fixes reverse engineering the length of `TextType` / `BlobType` columns in MySQL which is important for proper SQL generation of distinct native `TINYTEXT`, `TEXT`, `MEDIUMTEXT`, `LONGTEXT`, `TINYBLOB`, `BLOB`, `MEDIUMBLOB` and `LONGBLOB` types.






[DBAL-849] [GH-554] Add support string date modifiers for SqlitePlatform Created: 26/Mar/14  Updated: 26/Mar/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 leonoff:

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

Message:

In some cases we need support of non-numeric date(datetime) modifiers.
For example if we store interval-value-field in the table. Sqlite doesn't support 'field day' modifier. Common solution for this case is concatenate interval to a string: '' || field || 'day'






[DBAL-840] [GH-546] [DBAL-474] Fix filtering sequence names on PostgreSQL Created: 19/Mar/14  Updated: 19/Mar/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 deeky666:

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

Message:

The PostgreSQL schema manager has to filter sequence names before actually creating `Sequence` objects to avoid errors on accessing sequence database objects where the user has not enough privileges for.
The reason for this is that retrieving sequence attributes other than the sequence name requires accessing the particular sequence database object directly which requires the connected user to have enough privileges. This might not always be the case if for example a particular user can only access certain schemas but not others.
This patch might not be the best solution but a good compromise IMO. Changing the `AbstractSchemaManager` to filter sequence names before creating `Sequence` objects might affect other platforms and could also perhaps break BC. Furthermore this issue is completely PostgreSQL specific as it is the only currently supported platform not having a sequence's attributes stored directly in the system catalogs (AFAIK).






[DBAL-839] [GH-545] [DBAL-835] Quote old column name in rename column SQL Created: 19/Mar/14  Updated: 19/Mar/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 deeky666:

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

Message:

Quotes old column name in `ALTER TABLE` statements if necessary when a column gets renamed.

Note: The `AbstractSQLServerPlatformTestCase::getQuotedAlterTableRenameColumnSQL()` method need adjustments as soon as PR #542 gets merged (the `ALTER TABLE` statements need to be removed).






[DBAL-835] Old column name not quoted during column rename in MySQL Created: 12/Mar/14  Updated: 19/Mar/14

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

Type: Bug Priority: Major
Reporter: Arttu Manninen Assignee: Steve Müller
Resolution: Unresolved Votes: 0
Labels: None
Environment:

CentOS with Doctrine 2.3 MySQL 5.5.31



 Description   

This is a broken feature, because escaping only sometimes (behavior at least in 2.3, if it has not been fixed after that) leads to breaking things. It is possible to CREATE a column named `usage` (without any backticks in the code), but things break from that point on. If I try to change the column name to a non-reserved word later, ALTER TABLE syntax will break

[Doctrine\DBAL\DBALException]
An exception occurred while executing 'ALTER TABLE products CHANGE usage purpose VARCHAR(256) NOT NULL':

SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'usage purpose VARCHAR(256) NOT NULL' at line 1

Migrating down then again escapes the column name even if it wasn't escaped in the definition.

I found a ticket from 2012 describing that column names using reserved keywords should be escaped manually, but since migrations will lead into a dead-end with at least using `usage` as a column name, this feature is somewhat broken.



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

Arttu Manninen There have been some fixes around quoting identifiers in DDL lately. It seems there is one missing around $oldColumnName in MySqlPlatform::getAlterTableSQL().
I have moved this issue to DBAL as it is an issue there.

Comment by Steve Müller [ 19/Mar/14 ]

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





[DBAL-831] [GH-540] unit test to create constraint on forced lowercase table in oracle Created: 04/Mar/14  Updated: 04/Mar/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}

````






[DBAL-828] [GH-538] Json_Array: Convert database null to PHP null instead of empty array Created: 04/Mar/14  Updated: 17/Apr/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 localheinz:

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

Message:

Related to https://github.com/doctrine/doctrine2/pull/968.



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

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





[DBAL-827] [GH-537] Update PDOConnection.php Created: 04/Mar/14  Updated: 04/Mar/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 mmicael1:

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

Message:

Remove lot of if making beautifull code using call_user_func_array






[DBAL-821] [GH-532] DBAL-807 [DBAL-807] - Added failing test reproduces a problem. Created: 22/Feb/14  Updated: 22/Feb/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

Issue Links:
Reference
relates to DBAL-807 Index renaming in postgresql does not... In Progress
is referenced by DBAL-822 [GH-533] [DBAL-807] Respect schema wh... Open

 Description   

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

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

Message:

Added failing test reproduces problem, decribed in ticket http://www.doctrine-project.org/jira/browse/DBAL-807



 Comments   
Comment by Doctrine Bot [ 22/Feb/14 ]

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





[DBAL-822] [GH-533] [DBAL-807] Respect schema when renaming indexes Created: 22/Feb/14  Updated: 22/Feb/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

Issue Links:
Reference
relates to DBAL-821 [GH-532] DBAL-807 [DBAL-807] - Added ... Open
relates to DBAL-807 Index renaming in postgresql does not... In Progress

 Description   

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

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

Message:

Statements for renaming indexes have to include the schema name if applicable.



 Comments   
Comment by Doctrine Bot [ 22/Feb/14 ]

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





[DBAL-816] [GH-529] fix for postres listTableNames Created: 18/Feb/14  Updated: 18/Feb/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 MaksSlesarenko:

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

Message:

fix for listTableNames to return unescaped table names






[DBAL-811] [GH-527] Birko boolean conversion Created: 12/Feb/14  Updated: 12/Feb/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 birko:

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

Message:

Added platform specific conversion form database Boolean type to PHP bool type






[DBAL-808] [GH-525] Added flags support for mysqli::real_connect in Mysqli driver. Created: 08/Feb/14  Updated: 08/Feb/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 marcini:

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

Message:

This is necessary if you want to set connection options like compression or SSL encryption.

Recently I wanted to use DBAL with Mysqli driver and I noticed that there is no possibility to enable connection compression, which is done in mysqli by setting flags to mysqli::real_connect. DBAL Mysqli driver lacks support for setting any flag, so I decided to propose my change to add such possibility.






[DBAL-804] [GH-523] SQLSTATE[HY093]: Invalid parameter number: parameter was not defined Created: 06/Feb/14  Updated: 08/Feb/14

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

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

OSX 10.8, PHP5.4, MySQL56


Issue Links:
Duplicate
is duplicated by DBAL-803 SQLSTATE[HY093]: Invalid parameter nu... Resolved

 Description   

I am using this code from documentation

QueryBuilder Positional with ?
$query = $this->subject->getDatabaseHandle()->createQueryBuilder();
$query->delete($this->testTable)->where($this->testFieldSecond . ' = ?')
$query->setParameter(1, (int)$GLOBALS['EXEC_TIME']);
$query->execute();

... and I also tried

QueryBuilder Positional with ?1
$query = $this->subject->getDatabaseHandle()->createQueryBuilder();
$query->delete($this->testTable)->where($this->testFieldSecond . ' = ?1')
$query->setParameter(1, (int)$GLOBALS['EXEC_TIME']);
$query->execute();

but I got this error:

Error in test case deletePositionalParameter
File: vendor/doctrine/dbal/lib/Doctrine/DBAL/DBALException.php
Line: 91
An exception occurred while executing 'DELETE FROM test_t3lib_dbtest WHERE fieldblub = ?' with params [1391699318]:

SQLSTATE[HY093]: Invalid parameter number: parameter was not defined

When I provide a type to setParamter like

QueryBuilder Positional with ?1 and type
$query = $this->subject->getDatabaseHandle()->createQueryBuilder();
$query->delete($this->testTable)->where($this->testFieldSecond . ' = ?1')
$query->setParameter(1, (int)$GLOBALS['EXEC_TIME'], \PDO::PARAM_INT);
$query->execute();

or when I changed it to a named query it works

QueryBuilder Positional with named query
$query = $this->subject->getDatabaseHandle()->createQueryBuilder();
$query->delete($this->testTable)->where($this->testFieldSecond . ' = :test')
$query->setParameter(':test', (int)$GLOBALS['EXEC_TIME']);
$query->execute();

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

Message:

Creating Unit Tests to proof the behavior. Its my first PR and I
don't know if I created the Unit Test in the right place. It was the
location where the test actually writing to database which is needed
provoke the error.

DBAL-803 #Provides a test for this issue



 Comments   
Comment by Doctrine Bot [ 08/Feb/14 ]

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

Comment by Benjamin Eberlei [ 08/Feb/14 ]

Fixed in the docs.





[DBAL-805] [GH-524] Added new test WriteTest::testEmptyIdentityInsert(). Created: 06/Feb/14  Updated: 06/Feb/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 josemalonsom:

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

Message:

I added a missing test for AbstractPlatform::getEmptyIdentityInsertSQL().






[DBAL-800] [GH-522] Update DB2Platform.php to add ORDER BY data. Created: 30/Jan/14  Updated: 30/Jan/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 ellier:

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

Message:

Added ORDER BY to doModifyLimitQuery in DB2Platform.php.






[DBAL-798] [GH-520] [WIP] Add pdo informix driver support Created: 28/Jan/14  Updated: 28/Jan/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 josemalonsom:

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

Message:

I have created this branch to add support to PDO_INFORMIX in DBAL.

First I had put a new topic in the doctrine-dev group (https://groups.google.com/forum/#!topic/doctrine-dev/gndS00nxSQA) where i explain some issues i have.






[DBAL-794] [GH-517] Fix method signature in Doctrine\DBAL\Driver\Connection Created: 19/Jan/14  Updated: 29/Jan/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

Issue Links:
Duplicate
is duplicated by DBAL-799 [GH-521] Fix Connection Interface Resolved

 Description   

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

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

Message:

The method ``prepare`` must have an optional driverOptions parameter to be compatible with class which implement the interface Doctrine\DBAL\Driver\Connection.

To avoid this problem:

HipHop Fatal error: Declaration of Doctrine\DBAL\Driver\PDOConnection::prepare() must be compatible with that of Doctrine\DBAL\Driver\Connection::prepare() in /home/travis/build/symfony/symfony/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php on line 30






[DBAL-796] [GH-518] support to ibmi db2 - as400 Created: 22/Jan/14  Updated: 22/Jan/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 nfrignani:

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

Message:

support for ibmi db2 (as400)
some code in DB2Platform doesn't yet work on ibmi db2






[DBAL-777] [GH-503] Decode hex-encoded clobs/blobs when using pgsql on windows Created: 09/Jan/14  Updated: 09/Jan/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 Seldaek:

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

Message:

http://stackoverflow.com/a/15112973 explains the why. It'd be great to offer support for this natively. I run an `->executeQuery('SET bytea_output=escape')` every time now as a workaround but that's not very nice.



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

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

Comment by Jordi Boggiano [ 09/Jan/14 ]

This was reopened now





[DBAL-778] [GH-504] Decode hex-encoded clobs/blobs when using pgsql on windows Created: 09/Jan/14  Updated: 09/Jan/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 Seldaek:

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

Message:

http://stackoverflow.com/a/15112973 explains the why. It'd be great to offer support for this natively. I run an `->executeQuery('SET bytea_output=escape')` every time now as a workaround but that's not very nice.






[DBAL-753] Evaluate owncloud patch for Oracle quoting Created: 31/Dec/13  Updated: 01/Jan/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: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

See https://github.com/owncloud/3rdparty/commit/7ae81563894b971e51cee7bdb0ac2da83ecc5149



 Comments   
Comment by Steve Müller [ 01/Jan/14 ]

There are already several open tickets concerning general quotation issues. The patch might solve a little subset of the root problem which is actually really tricky. We need a more general and robust approach that works on all platforms.
See DBAL-96





[DBAL-746] [GH-479] [DBAL-624] Fix parsing parameters in comments Created: 29/Dec/13  Updated: 29/Dec/13

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/479

Message:

Parameter placeholders should not be parsed out of comments in statements.






[DBAL-730] [GH-464] [DBAL-139] [WIP] Finish CACHE option implementation for sequences Created: 23/Dec/13  Updated: 23/Dec/13

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/464

Message:

@beberlei Started implementation for DBAL-139(http://www.doctrine-project.org/jira/browse/DBAL-139) in commit https://github.com/doctrine/dbal/commit/e8efcd7621e85003f3ce496bc26a108b53371838 and https://github.com/doctrine/dbal/commit/d397c005dd3ff3d48a81eeb47c2a0d74d6b7400d which was first drafted in PR #202. It's about adding a cache option for sequences.

*The following missing aspects of the implementation were added:*

  • SQL Server support
  • SQL Anywhere support
  • Reverse engineering the cache option with the schema managers
  • Comparator implementation
  • Schema::createSequence() adjustment
  • More tests

*Additional optimizations:*

  • Rename `$cache` to `$cacheSize` in Sequence (unified naming with `$allocationSize`)
  • More strict input validation for cache size values in Sequence to avoid SQL generation errors
  • Better API documentation
  • Unified `getSequenceCacheClause()` method on all platforms

*Todo:*

  • Fix comparator issues (see below)
  • Finish test suite for this (depends on comparator issues solution)

*Comparator issues*
The comparator will get into trouble when comparing cache size values. To get an understanding of this I'll first explain how cache size values evaluate to the database:

  • `null` -> No cache size specified, don't generate cache clause for sequences and use platform's default
  • `0` -> Explicitly disable caching for sequences, generates `NOCACHE` clause on platforms
  • every other positive value is an explicite specification of the cache size and results in `CACHE <size>` clause

Now there are two problems.

First one is that a value of `1` has a special meaning on some platforms, too. Oracle does not accept it and throws an error as the minimum allowed value is `2`. PostgreSQL allows a value of `1` but in fact interprets it as `NOCACHE`. SQL Server and SQL Anywhere accept a value of `1` but the behaviour is unclear compared to an explicite `NOCACHE` on these platforms. Now I am assuming that a cache size of `1` maybe also physically has the same effect as if specifying no cache at all and that this is more of a "compatibility" value and we maybe should not allow it at all to preserve portability throughout the vendors.

The second problem is the `null` value for `$cacheSize` in Sequences. This tells the vendor to use it's own specific default cache size which differs on all platforms. The comparator will always mark a sequence as changed then when `null` was initially defined for the sequence and the sequence is introspected from database again. This will lead to repeated `ALTER SEQUENCE` statements in the schema tool which is not good. Also we cannot determine in the platform itself if the sequence has really changed as there currently is no `SequenceDiff` class which could get passed to `AbstractPlatform::getAlterSequenceSQL()`. Instead we only get the changed sequence object. I have put together some [examples](https://gist.github.com/deeky666/6c4e47a275b1c9e7c068) to clarify on what I mean as it is hard to explain.

So I'm asking for opinions and input on this






[DBAL-731] [GH-465] [DBAL-423] Optimize non-native GUID type declaration Created: 23/Dec/13  Updated: 23/Dec/13

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/465

Message:

Currently non-native GUID type is mapped to `VARCHAR(255)` which is not effective as GUID always has a fixed length of 36 characters. Therefore it should be mapped to `CHAR(36)` instead.






[DBAL-715] Using caching with fetchColumn() of single row does not work Created: 20/Dec/13  Updated: 20/Dec/13

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

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

Issue Links:
Reference
is referenced by DBAL-468 [GH-288] Fix fetchColumn not caching Resolved

 Description   

The caching mechanism only triggers when the cursor is fully iterated and the result is closed. This breaks caching for code of the kind:

$cnt = $conn->executeQuery($sql)->fetchColumn();





[DBAL-624] Parameter in comments is parsed Created: 03/Oct/13  Updated: 22/Nov/13

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

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

Issue Links:
Reference
relates to DBAL-552 Colon (":") in field name treats like... Resolved

 Description   

Text in comment is parsed as params.
I.e.:
select abc – :par
from table

select abc /* :par */
from table



 Comments   
Comment by Steve Müller [ 21/Nov/13 ]

Which platform / driver do you refer to? Maybe a duplicate of this?
http://www.doctrine-project.org/jira/browse/DBAL-124

Comment by Vitaliy [ 22/Nov/13 ]

No platform / driver depend. I try test class SQLParserUtils in separate module. And this sql parsed wrong.





[DBAL-602] Deprecate Migrations in favor of stable tools Created: 12/Sep/13  Updated: 31/Jan/14

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

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

Sub-Tasks:
Key
Summary
Type
Status
Assignee
DBAL-603 DbDeploy Support Sub-task Open Benjamin Eberlei  
DBAL-604 Liquibase Support Sub-task Open Benjamin Eberlei  
DBAL-605 Phinx Support Sub-task Open Benjamin Eberlei  

 Description   

The Migrations project is very big and currently unmaintained, even if there is definately need for a solution of the migration problem.

The idea would be introduce a subcomponent in DBAL that delegates this to proven tools (DbDeploy and Liquibase, and Phinx for PHP based).

The functionality Doctrine should provide is integration with the \Doctrine\DBAL\Schema API. Three operations come to mind:

  • status - What version are we? Do we need to execute more versions?
  • migrate - Execute the migration tool
  • create-migration - Create a new migration file of the underlying platform.

The last operation needs to check if no versions need to be applied at the moment.

interface MigrationTool
{
   /** @return MigrationCurrentStatus */
   public function getStatus();

   /** @return MigrationPerformedStatus */
   public function migrate($toVersion = null);

   /** @return MigrationRolledBackStatus */
   public function rollback($toVersion = null);

   /** @return MigrationCreatedStatus */
   public function create(Schema $toSchema);
}

Every tool implements this interface and then we need 3 new commands for "status", "migrate" and "rollback". The "create" command can only be implemented in the context of the ORM.



 Comments   
Comment by Christophe Coevoet [ 12/Sep/13 ]

What is the idea here ?

I don't agree about removing the Migrations project in favor of using only the schema diff tool (which we already have as a command in the ORM btw). Migrating is not only about updating the schema. It also requires migrating data. Otherwise, it is not safe to use in production. This is why the

{doctrine:schema:update}

command displays a warning before running.
A good example is adding a new non-nullable unique field. Applying the schema update works on an empty DB but fails when the table already contains data.

Comment by Benjamin Eberlei [ 12/Sep/13 ]

Christophe Coevoet The idea is not to keep only ORM Schema-Tool, which is really only a Dev-Tool. We would rather add support for DbDeploy, Liquibase and Phinx into DBAL via some integration sub-component and using DBAL\Schema to create migration files for their formats.

Comment by Miha Vrhovnik [ 04/Jan/14 ]

There is also http://dbv.vizuina.com/

Comment by Jonathan Cardoso Machado [ 31/Jan/14 ]

The command line support is going to stay right? The idea here is to use third party deploy framework, but with specific bindings to use with Doctrine, Am I right?





Deprecate Migrations in favor of stable tools (DBAL-602)

[DBAL-605] Phinx Support Created: 12/Sep/13  Updated: 18/Sep/13

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

Type: Sub-task Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: None


 Comments   
Comment by Rob Morgan [ 18/Sep/13 ]

Hi Guys, I'm the lead developer for Phinx. Happy to give support here if needed.

Rob





Deprecate Migrations in favor of stable tools (DBAL-602)

[DBAL-604] Liquibase Support Created: 12/Sep/13  Updated: 12/Sep/13

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

Type: Sub-task Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None





[DBAL-600] Add support of joins in update statements when using DBAL QueryBuilder Created: 09/Sep/13  Updated: 23/Dec/13

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

Type: Improvement Priority: Major
Reporter: Konstantin Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Comments   
Comment by Steve Müller [ 23/Dec/13 ]

This is tricky as UPDATE statements based on JOINs are not in the SQL standard and therefore the syntax and support differs alot throughout the vendors. But could be doable with some effort.





[DBAL-599] Add support of insert and insert select statements in DBAL QueryBuilder Created: 09/Sep/13  Updated: 25/Nov/13

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

Type: Improvement Priority: Major
Reporter: Konstantin Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: None

Issue Links:
Reference
relates to DBAL-182 Insert and Merge Query Objects Open
relates to DBAL-320 allow SQL QueryBuilder to do INSERTS Resolved
is referenced by DBAL-636 QueryBuilder insert Resolved




[DBAL-587] Support for Triggers, Views, Procedures Created: 27/Aug/13  Updated: 27/Aug/13

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


 Description   

Schema should have support for triggers, views and stored procedures. Since this is not standardizable accross platforms easily, the idea is to allow arbitrary SQL DDL Statements to be registered on a Schema, maybe even qualified by platform.

$artifact = new SQLArtifact();
$artifact->setName('some_view_name');
$artifact->create('CREATE VIEW IF NOT EXISTS foo SELECT 1');
$artifact->drop('DROP VIEW foo');
$artifact->setPlatforms("mysql"); // accepts string or array, if nothing is set applies to ALL platforms.
$schema->addSQLArtifact($artifact);

During the SQL generation for the schema, the following will be appended to the currently generated SQL:

DROP VIEW foo;
CREATE VIEW IF NOT EXISTS foo SELECT 1

The drop part of the statement is always rendered before the create statement in the Create Schema Visitor. In the Drop schema listener only the drop part is used.






[DBAL-547] Evaluate moving away from prepared statements to sprintf() Created: 18/Jun/13  Updated: 18/Jun/13

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


 Description   

We are using prepared statements and parsing on top at the moment to implement things like array param quoting and such.

We should evaluate if it makes sense to introduce a strategy for preparing/parsing queries and make sprintf() usage a default in 3.0 instead of using prepared statements. At least for MySQL the PHP Driver guys are arguing for this kind of processing for years.






[DBAL-512] Update schema not working on MsSql due to no support for alter identity Created: 06/May/13  Updated: 16/Dec/13

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

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

Symfony 2.1, SQL Server 2008, driver: pdo_sqlsrv



 Description   

When running: php app/console doctrine:schema:update --force

[Doctrine\DBAL\DBALException]
An exception occurred while executing 'ALTER TABLE tableName ALTER COLUMN id INT IDENTITY NOT NULL':

SQLSTATE[42000]: [Microsoft][SQL Server Native Client 11.0][SQL Server]Incorrect syntax near the keyword 'IDENTITY'.

According to this stackoverflow http://stackoverflow.com/a/1049305/1833322 MSSQL does not support this query.



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

Obviously SQL Server doesn't support this. So what solution would you expect here? IMO such a scenario should be avoided as there is no reasonable way to deal with changing identity columns. I guess most people are not even aware of this. The solutions available are very risky (creating new schema and then migrating data for example) and can take very long to be finished and is extremly error prone. I don't know if we should support one of those workarounds.

Comment by Flip [ 27/Nov/13 ]

The bug is about the SQL statement that does not work.
1. One solution could be to prevent generating this statement and issue a warning instead. (not preferred)

Two other solutions are mentioned in that Stackoverflow post I mentioned, namely:
2. Create a new table with identity & drop the existing table
3. Create a new column with identity & drop the existing column

That is just the way things have to be done in SQL Server (unfortunately), so it wouldn't be a workaround. I think this is a very reasonable way and in fact similar solutions to similar problems have already been implemented into Doctrine. See http://www.doctrine-project.org/blog/doctrine-2-4-released.html "ALTER TABLE support for SQLite (by hason) by creating new tables, moving all the data and then renaming."

Comment by Benjamin Eberlei [ 13/Dec/13 ]

Flip not many people actually use Sqlite in production, its more of a "play database" with Doctrine, wheras SQL Server carries much more weigh. I don't want to implement this kind of workaround, Steve Müller what do you think is safe here?

Comment by Flip [ 13/Dec/13 ]

Not to argue .. but it's not a workaround

Really .. if it is ever implemented it would have to be in a few steps because SQL Server does not accept this one-line command like that. So basically when you don't want this solution it means that will never be implemented.

Talking about safe .. mind that the safety should also be ensured in other area's like 1. don't run --force on a production database 2. make backups. So when regarding the safety it's a very narrow area to take a look at. The operation could be setup in such a way that if the new table/column could not be created then the old one doesn't get deleted. That way you have always the safety like a database transaction.

I guess no point in making a Proof of Concept, because the general outline of the problem is actually not that complicated ..

Thx guys for the input on this issue.

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

Benjamin Eberlei we could of course use one of the approaches Flip mentioned, but the question is what to do in case something goes wrong during one of the steps required to alter an IDENTITY column. If it is acceptable that there exist "dead" tables/columns in case something goes wrong, we could try implementing that.





Deprecate Migrations in favor of stable tools (DBAL-602)

[DBAL-603] DbDeploy Support Created: 27/Feb/13  Updated: 12/Sep/13

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

Type: Sub-task Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   
  • DbDeploy Diff Generation
  • Schema Serialization
  • SchemaTool gets new event when diff is applied, then you can update a "stable" schema xml. On Generation new db deploy script, use current schema vs stable schema vom disc.





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

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

Type: Bug Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Unresolved 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






[DBAL-390] Wrap SQL for Selects in an Object for Metadata? Created: 23/Nov/12  Updated: 23/Nov/12

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





[DBAL-348] [GH-202] Fixed DBAL-139 Oracle's sequences with NOCACHE Created: 22/Sep/12  Updated: 22/Dec/13

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


 Description   

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

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

Message:



 Comments   
Comment by Benjamin Eberlei [ 22/Sep/12 ]

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

Comment by Benjamin Eberlei [ 22/Sep/12 ]

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

Comment by Benjamin Eberlei [ 22/Sep/12 ]

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

Comment by Benjamin Eberlei [ 23/Sep/12 ]

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

Comment by Doctrine Bot [ 22/Dec/13 ]

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





[DBAL-324] SchemaManager should first look into comment instead of infer the type first. Created: 17/Aug/12  Updated: 03/Jan/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: Guilherme Blanco Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 0
Labels: None


 Description   

When using schema tool, Doctrine tries to infer the Doctrine type via the mapped types in Platform.
It should first try to read from the comment; if found, ignore the Database type inference.



 Comments   
Comment by Benjamin Eberlei [ 29/Aug/12 ]

Why is this a bug? Can you say some more about why we need to do this and what error occurs?

Comment by Guilherme Blanco [ 29/Aug/12 ]

This issue is strictly correlated to the commit I've done here: https://github.com/doctrine/dbal/commit/e25c774dde971dc4afd40648e9ccd0af53b34ce9

Mainly, we may have legacy database that we do know how Doctrine should operate. Under this circumstance, we may want to add a comment to the field defining the Doctrine DBAL type.
Even though after doing this, Doctrine still complains (in my situation, a SET column type) that it's unable to handle this column type.

That happens because MySQL Schema Manager (and others) first looks for the column type:
https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Schema/MySqlSchemaManager.php#L112
https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Platforms/AbstractPlatform.php#L312
which automatically fails.

But if we first try to look for the commented data type:
https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Schema/AbstractSchemaManager.php#L884
And forget about the rest if it finds one definition there, it would allow even unknown data types to be managed instead of forcing to define the DBAL Type compatible.

Comment by Steve Tauber [ 14/May/13 ]

This also applies for a type of yaml.
Example:

/** @Column(type="yaml") */
protected $data = array();

./scripts/doctrine orm:schema-tool:update --dump-sql
ALTER TABLE meta CHANGE data data LONGTEXT NOT NULL;

Very frustrating.... Might be related to http://www.doctrine-project.org/jira/browse/DBAL-42

Comment by Steve Müller [ 03/Jan/14 ]

Steve Tauber You have defined a custom data type. You need to override `Type::requiresSQLCommentHint()` to return true in your custom data type, otherwise Doctrine cannot infer the custom type mapping from the column comment and the comparator will always detect changes between Yaml and LONGTEXT. This is not directly related to this issue here I think.
Guilherme Blanco I don't really get the issue you describe here. Is it maybe fixed already? Otherwise can you maybe try to explain again so that I can fix that?





[DBAL-321] [GH-184] Added INSERT support to dbal QueryBuilder Created: 13/Aug/12  Updated: 20/Dec/13

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


 Description   

This issue is created automatically through a Github pull request on behalf of Tim-Erwin:

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

Message:

See also http://www.doctrine-project.org/jira/browse/DBAL-320
Please review and commit as fits.



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

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

Comment by Doctrine Bot [ 20/Dec/13 ]

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





[DBAL-294] [GH-163] [WIP] Upsert support protoype. Created: 29/Jun/12  Updated: 20/Dec/13

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


 Description   

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

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

Message:



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

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





[DBAL-225] Add events for onBeginTransaction, onCommit, onCommitFailure Created: 13/Feb/12  Updated: 07/Sep/13

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

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


 Description   

Allow to switch a CommitFailure into a successful event.

This could be done by saving all insert/update/delete statements starting from begin transaction and then replaying them N-times until success is achieved.






[DBAL-221] Schema toSQL() and toDropSQL() both need to delegete creation/drop of schema-level elements Created: 13/Feb/12  Updated: 07/Sep/13

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

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


 Description   

The following schema-level changes have to be done before tables are created:

  • create Schema (PGSQL, MySQL, ...)
  • Create Federations (Azure)
  • Create Types (PGSQL, Oracle, ...)
  • Create Views, Stored Procedures, Triggers

We should add the following APIs:

array $sql AbstractPlatform::getCreateSchemaAdditionalStatements(Schema $schema);
$object = new SQLObject($sqlUpCommand, $sqlDropCommand);
$schema->addSQLObject($object);





[DBAL-218] Add Object for BulkInsert Abstraction Created: 05/Feb/12  Updated: 07/Sep/13

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

Type: Task Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: None





[DBAL-217] Introduction Interface for Connection Created: 05/Feb/12  Updated: 07/Sep/13

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

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





[DBAL-182] Insert and Merge Query Objects Created: 18/Nov/11  Updated: 25/Nov/13

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

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

Issue Links:
Reference
relates to DBAL-320 allow SQL QueryBuilder to do INSERTS Resolved
is referenced by DBAL-599 Add support of insert and insert sele... Open
is referenced by DBAL-636 QueryBuilder insert Resolved

 Description   

We are missing Insert and Merge Query Objects.

See Drupal DBTNG:

Merge: http://drupal.org/node/310085
Insert: http://drupal.org/node/310079



 Comments   
Comment by Benjamin Eberlei [ 18/Nov/11 ]

From the first glance: Drupal API has some problems in that it assumes literal values are the default, which makes working with them simple if no expression is necessary. But inconsistent otherwise.

Implementation Details:

  • Difference compared to QueryBuilder is that these objects are no builders, but actually executors.
  • Don't assume Literals
  • Creation is delegated to Platform (Runtime API of a Vendor)
{conn}
$conn->createInsertQuery();
$conn->createMergeQuery();{conn}

Sample API:

$conn->createInsertQuery($tbl)->fields(array('foo', 'bar'))->values(array('?', '?'))->(array(1, 2))->execute();
$conn->createInsertQuery($tbl)->fields(array('foo', 'bar'))->params(array(1, 2))->execute(); // values(?, ?) is implicit.
$conn->createInsertQuery($tbl)->fields(array('foo', 'bar'))->params(array('NOW()', '1'))->execute(); // if no "params" set assume execute once.
$conn->createInsertQuery($tbl)->fields(array('foo', 'bar'))->value('foo', 'NOW())->params(array(1))->params(array(2))->execute();
$conn->createInsertQuery($tbl)->fields(array('foo', 'bar'))->select($queryBuilder)->execute();

Merge: I dont know yet:

problem i see here is that people mistake values() for a "safe" method and pass values in there that should be quoted instead.





[DBAL-163] Upsert support in DBAL Created: 10/Sep/11  Updated: 07/Sep/13

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

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


 Description   

Upsert support in DBAL (replace, insert into usw..)



 Comments   
Comment by Miha Vrhovnik [ 11/Jun/12 ]

FYI: http://www.depesz.com/2012/06/10/why-is-upsert-so-complicated/





[DBAL-95] Interbase/Firebird support Created: 26/Feb/11  Updated: 12/Mar/13

Status: Open
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: 4
Labels: None


 Description   

Implemented support for Interbase/Firebird dialects






[DBAL-76] PostgreSQL Platform list* SQL code is in need of serious love Created: 12/Dec/10  Updated: 08/Jun/11

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

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


 Description   

The Postgres Schema code is very hard to read and inconsistent across the board. Some use pg_class, some pg_tables. Namespaces /Schema are not always properly checked for. There should be a really unified way on how to approach schema query issues.



 Comments   
Comment by Denis [ 08/Jun/11 ]

I'm not sure what this ticket is about exactly, but...

"Namespaces /Schema are not always properly checked for."

Usually, one would not want to specify them and set the search_path instead. Or are you meaning the schema analysis queries used internally? (If so, yes, it kind of sucks in that case, but note that there are a bunch of *_is_visible() methods, e.g. pg_catalog.pg_table_is_visible(rel.oid) which will strip out invisible schemas directly. This may be simpler than injecting schema references all over the place in that it also processes permissions.)

Also, note that PG has a whole bunch of pg_catalog views, which are available in the information_schema.





[DBAL-31] Move Schema related Creation code from AbstractPlatform to AbstractSchemaManager Created: 04/Jul/10  Updated: 28/Dec/13

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

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


 Description   

Move Schema related Creation code from AbstractPlatform to AbstractSchemaManager



 Comments   
Comment by Benjamin Eberlei [ 08/Aug/10 ]

Scheduled for Beta4

Comment by Roman S. Borschel [ 16/Aug/10 ]

If this task is more complex and requires larger refactorings we can re-evaluate it in a post-2.0 release.

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

Benjamin Eberlei Do you still remember what is meant by this ticket? Could be solved already...





[DBAL-873] [GH-571] Introduced a Transaction object Created: 18/Apr/14  Updated: 18/Apr/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 BenMorel:

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

Message:

This is a first draft on the idea of a Transaction object, as suggested by @guilhermeblanco and @beberlei in doctrine/doctrine2#949.

This makes the following changes to `Connection`:

  • *Adds* the following methods:
  • `createTransaction()` : begins a transaction and returns the associated `Transaction` object
  • `getTransactionManager()` : returns the `TransactionManager`
  • *Deprecates* `beginTransaction()` in favour of `createTransaction()`
  • *Deprecates* the following methods, in favour of their counterparts on `Transaction`:
  • `commit()`
  • `rollBack()`
  • `setRollbackOnly()`
  • `isRollbackOnly()`
  • *Deprecates* the following methods, in favour of their counterparts on `TransactionManager`:
  • `isTransactionActive()`
  • `getTransactionNestingLevel()`
  • `setNestTransactionsWithSavepoints()`
  • `getNestTransactionsWithSavepoints()`

The new way of dealing with transactions is then:

$transaction = $connection->createTransaction();
$transaction->commit();

It also automatically propagates `commit()` and `rollback()` to nested transactions:

$transaction1 = $connection->createTransaction();
$transaction2 = $connection->createTransaction();
$transaction1->commit(); // will commit $transaction2 then $transaction1

Overall, it's not a complicated change, does not introduce any BC break, and passes all existing tests.

I'm looking forward to hearing what you think!






[DBAL-872] [GH-570] Add support for out cursor in OCI8 Created: 18/Apr/14  Updated: 18/Apr/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 Juliens:

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

Message:

I don't know if it is the best solution, but it's a beginning.






[DBAL-867] Doctrine\DBAL\Driver\Connection should be marked as an internal interface Created: 16/Apr/14  Updated: 22/Apr/14

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

Type: Documentation Priority: Major
Reporter: Christophe Coevoet Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Currently, the main entry point Doctrine\DBAL\Connection is documented as a wrapper around Doctrine\DBAL\Driver\Connection.
This is very misleading and encourages other library to typehint against Doctrine\DBAL\Driver\Connection rather than Doctrine\DBAL\Connection. See https://github.com/symfony/symfony/pull/10720 for the original discussion.

However, the discussion in https://github.com/doctrine/dbal/pull/414#discussion_r7688765 implies that they should actually not be related together (but it cannot be fixed for BC reasons). The phpdoc should at least be changed



 Comments   
Comment by Guilherme Blanco [ 21/Apr/14 ]

This issue was fixed some time ago.

Commit reference: https://github.com/doctrine/dbal/commit/5fdedc4f8f304e8035580807bd36d59e97a87265

Comment by Steve Müller [ 22/Apr/14 ]

Guilherme Blanco How is your commit reference related to this issue?

Comment by Guilherme Blanco [ 22/Apr/14 ]

Steve Müller The suggestion about Doctrine\DBAL\Connection and Doctrine\DBAL\Driver\Connection started around the misleading support of ping and how to consistently support it across different drivers.
The commit reference I pointed out is Benjamin Eberlei's resolution to remove misleading phpdoc around ping support (which is also highlighted in the ticket as "phpdoc should at least be changed").
If there's anything else that is missing, I'm probably not seeing. All I've done is followed dbal's discussion. =\

Comment by Christophe Coevoet [ 22/Apr/14 ]

Your commit does not fix it at all. Benjamin Eberlei's comment was about the ping method only indeed. But he explained that Doctrine\DBAL\Connection should actually not be a Doctrine\DBAL\Driver\Connection except for legacy reasons, which is why makign it implement Doctrine\DBAL\Driver\PingableConnection was a bad idea even if it has a ping method.

My issue is related to the description of the class itself: https://github.com/doctrine/dbal/blob/aa2ed45ade6582a24e4f72f674f6989873d72112/lib/Doctrine/DBAL/Connection.php#L36
It still describes it as a wrapper around the driver connection, making other devs think that the right typehint in other libraries is the internal driver connection. See the discussion in the Symfony PR I linked

Comment by Guilherme Blanco [ 22/Apr/14 ]

So... it's reopened. I'll look into this later today.





[DBAL-866] Foreign Key Constraints does not work with Doctrine/Symfony and SQLite Created: 12/Apr/14  Updated: 22/Apr/14

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

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

PHP 5.5.9, SQLite3 module version 0.7-dev, SQLite Library 3.8.3.1



 Description   

I have posted a question on stackoverflow already to get help on this issue, but nobody could give me a sufficient answer. See here.

#370 says that support for foreign keys support for SQLite has been implemented. But in my case it does not work. I have defined two entities:

Unable to find source-code formatter for language: yaml. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml
Category:
    type: entity
    id:
        id:
            type: integer
            id: true
            generator:
                strategy: AUTO
    oneToMany:
        ministries:
            targetEntity: Ministry
            cascade: [persist]
            mappedBy: category

And

Unable to find source-code formatter for language: yaml. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml
Ministry:
    type: entity
    id:
        id:
            type: integer
            id: true
            generator:
                strategy: AUTO
    manyToOne:
        category:
            targetEntity: Category
            inversedBy: ministries
            joinColumn:
                name: category_id
                nullable: false
                onDelete: CASCADE

But when I delete a category, the ministry entities do not get deleted, although the constraint should cascade. What am I missing?

Do I have to configure anything to get that working or is it a bug?



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

While some FK functionalities are supported by the DBAL, I reverted the feature in https://github.com/doctrine/dbal/commit/7282289fee625a24c26c1fccc0474e8ca583470f since it was too clunky, so the ORM doesn't recognize the platform as a platform that supports FKs.





[DBAL-874] [GH-572] Fix reverse engineering quoted table names on PostgreSQL Created: 22/Apr/14  Updated: 22/Apr/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 deeky666:

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

Message:

Commit https://github.com/doctrine/dbal/commit/83fe296de44ef3e2f04f2342021f656a797787ec introduced a bug with reverse engineering table details for tables with names requiring quotation (reserved keyword, non-identifier characters, case-folded) on PostgreSQL.
`PostgreSqlPlatform::getListTablesSQL()` fetches table names quoted if necessary with `quote_ident(tablename)` which in turn causes other `getListTable*SQL($table)` to fail retrieving results if the table name is quoted. Those methods always have to use unquoted table names in their statements.

See https://github.com/ZF-Commons/ZfcUserDoctrineORM/issues/77 for more details.






[DBAL-875] [GH-573] [DBAL-834] Fix order by with aggregate function(s) for limit/offset queries on SQL Server Created: 23/Apr/14  Updated: 23/Apr/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 deeky666:

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

Message:

When modifying a query with limit/offset clauses on SQL Server, using aggregate functions, the platform generates wrong SQL.
See http://www.doctrine-project.org/jira/browse/DBAL-834






[DBAL-837] Cannot drop index needed in a foreign key constraint Created: 17/Mar/14  Updated: 17/Mar/14

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

Type: Bug Priority: Minor
Reporter: Cliff Odijk Assignee: Steve Müller
Resolution: Unresolved Votes: 0
Labels: None
Environment:

MariaDB version 10.0.7
InnoDB version 5.6.10
doctrine/orm version v2.4.1
doctrine/dbal version v2.4.2


Issue Links:
Reference
relates to DBAL-732 MySQL 5.6 - Cannot change column 'fkP... Open

 Description   

I'm trying to remove an relation from an entity and i'm getting an error that it could not be executed. After testing it, it's missing the DROP FOREIGN KEY query.

The generated SQL is:

DROP INDEX IDX_DCE815B325C79A8C ON moveMembers;
ALTER TABLE moveMembers DROP fkAccessId;

When I use --force to execute it I get the following error:

[Doctrine\DBAL\DBALException]
An exception occurred while executing 'DROP INDEX IDX_DCE815B325C79A8C ON moveMembers':

SQLSTATE[HY000]: General error: 1553 Cannot drop index 'IDX_DCE815B325C79A8C': needed in a foreign key constraint

[PDOException]
SQLSTATE[HY000]: General error: 1553 Cannot drop index 'IDX_DCE815B325C79A8C': needed in a foreign key constraint



 Comments   
Comment by Cliff Odijk [ 17/Mar/14 ]

Maybe related to DBAL-732?





[DBAL-732] MySQL 5.6 - Cannot change column 'fkProjectId': used in a foreign key constraint Created: 24/Dec/13  Updated: 18/Mar/14

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

Type: Bug Priority: Minor
Reporter: Cliff Odijk Assignee: Steve Müller
Resolution: Unresolved Votes: 1
Labels: None

Issue Links:
Reference
is referenced by DBAL-837 Cannot drop index needed in a foreign... Open

 Description   

I'm using doctrine migrations to change a null field to a not null field. MySQL 5.6 is strict on altering tables with foreign key constraint's.

Generated SQL

ALTER TABLE badges CHANGE fkProjectId fkProjectId INT NOT NULL

Result in the following error

Cannot change column 'fkProjectId': used in a foreign key constraint 'FK_1483A5E9F28AE4EA'

More info:

As of 5.6.7, the server prohibits changes to foreign key columns with the potential to cause loss of referential integrity. A workaround is to use ALTER TABLE ... DROP FOREIGN KEY before changing the column definition and ALTER TABLE ... ADD FOREIGN KEY afterward.

Original issue:



 Comments   
Comment by Marco Pivetta [ 24/Dec/13 ]

Cliff Odijk what versions of DBAL/ORM are affected by the bug?

Comment by Cliff Odijk [ 24/Dec/13 ]

Doctrine 2.3.4 / 2a37b007dda8e21bdbb8fa445be8fa0064199e13.

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

Marco Pivetta I wonder whether we should introduce MySqlPlatform567 to fix this which adds this behaviour. We could also fix this is MySqlPlatform directly but I don't know if this impacts performance for older versions of MySQL that don't require this behaviour.

Comment by Timothée Martin [ 09/Jan/14 ]

I encounter the same issue with doctrine/dbal 2.4.2 (commit fec965d330c958e175c39e61c3f6751955af32d0).

Have you any idea of when this bug will be fixed? Or may be can you guide me on how to fix it and I could make a PR on doctrine/dbal.

Thanks.

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

Cliff Odijk , Timothée Martin I will work on this issue as soon as I have time. Expect a fix for this in the upcoming weeks. Thank you for your patience.

Comment by Cliff Odijk [ 28/Jan/14 ]

The same error occurs with MariaDB version 10.0.7

  • InnoDB version 5.6.10
  • doctrine/orm version v2.4.1
  • doctrine/dbal version v2.4.2
Comment by Steve Müller [ 18/Mar/14 ]

I already started work on this but didn't have time to finish it, yet. I will try to find some time for this this evening.





[DBAL-662] Supporting PHP 5.5 DateTimeImmutable Created: 14/Nov/13  Updated: 03/Jan/14

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

Type: New Feature Priority: Minor
Reporter: Christophe Coevoet Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: mapping, schematool


 Description   

Introducing new types converting dates into a DateTimeImmutable rather than a DateTime could be useful for applications prefering the use of immutable datetimes (and relying on PHP 5.5+).

The existing types already support setting a DateTimeImmutable in a field mapped with the datetime type, as it does not check the value against DateTime but only expects a format method. but the conversion from DB to PHP will always produce a mutable DateTime instance, thus preventing to use the immutable flavour consistently.

Not that this is a low priority issue as any code interacting with third party packages will probably need to use DateTime anyway because of the typehints (typehinting DateTimeInterface would not work if you need to keep compatibility with 5.4)

If DBAL 3.0 bumps the minimal supported version to 5.5 (which might be possible depending of the release date of 3.0), we could decide to break BC and use the immutable flavour in the datetime type directly.



 Comments   
Comment by Steve Müller [ 03/Jan/14 ]

Christophe Coevoet Should we mark that for 3.0 as suggested? Or do you see any need/possibility of implementing this already in 2.x branch?





[DBAL-631] NuoDB compatibility Created: 15/Oct/13  Updated: 15/Oct/13

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

Type: Improvement Priority: Minor
Reporter: Pierre Bonneau Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Hello,

I'm looking for a scalable SQL database, and I found nuoDB(old nimbus DB) that seems to do the job on paper.
My company tend to encourage us to move to many small VM architecture in place of large machines.

I wanted to know if such a DB engine was going to be supported in the near future, or if it was now.
For what I saw, the only really scalable solution I have now is nosql DB as mongo DB with doctrine.
As Doctrine is a requirment on our application, I was condering if you had any feedback for us on this subject.

Best regards, and thank you for your work.

Pierre Bonneau



 Comments   
Comment by Christophe Coevoet [ 15/Oct/13 ]

The best way to have NuoDB support in DBAL is probably to contribute it.
Introducing new drivers is best done by people using them (because they actually need it, and because they can more easily test them)

You will need to provide 3 classes (and their tests):

Comment by Pierre Bonneau [ 15/Oct/13 ]

Hello,

I already asked the question to NuoDB company, waiting their answer.
I'm absolutly not familiar with it, so I'm not very confident in the fact I would be able to provide a correct interface for this server.

I read mysql driver, shema and platform as an example. Driver and shema development should be dueable... but platform is totally out of my scope / scope... It would require a good knowledge of the database, and honnestly, I need only to perform 3 operations on it : INSERT / UPDATE and SELECT... without even a join. Would it be possible to let the other method empty and to let the community fill the blank ?

Thank you,
Pierre

Comment by Christophe Coevoet [ 15/Oct/13 ]

unfortunately, you need more than this in case you are using the ORM, because the ORM needs more methods from the platform (many of them has been added based on the needs of the ORM). However, the nuodb doc should only implementing these methods: doc.nuodb.com/display/doc/SQL+Reference

Comment by Pierre Bonneau [ 15/Oct/13 ]

Hello,

Thank you for your answer...

If we want to be compliant to Doctrine, is there a number of method that are required, and some other that are usefull?
I mean I can implement the method, but do nothing in some of them. The next user who need more will develop the module, or we will do later if needed.

The idea for me is to lower the cost, and to not pay on my project budget the entire connectivity...
I'm not againts speding 3-5 man day in this subject, but more will be an issue regarding the total amount of day I have on the project.

Pierre





[DBAL-423] Type GUID = VARCHAR(255) on platforms that don't have a native GUID support Created: 25/Jan/13  Updated: 08/Mar/14

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

Type: Improvement Priority: Minor
Reporter: amr Assignee: Steve Müller
Resolution: Unresolved Votes: 1
Labels: None


 Description   

I'm using MySQL with entities that have GUID ids. Therefore I'm using @ORM\Column(type="guid") for the ORM mapping. As MySQL does not have a native GUID data type, it gets mapped to type="string" with a default length of 255 -> VARCHAR(255). I don't really understand why we don't limit the length to 36, which is the fixed length for GUIDs. You could even think about using CHAR(36) for MySQL.

-> see Doctrine\DBAL\Platforms\AbstractPlatform -> getGuidTypeDeclarationSQL()



 Comments   
Comment by Steve Müller [ 23/Dec/13 ]

Patch PR: https://github.com/doctrine/dbal/pull/465

Comment by Michael Kühn [ 28/Feb/14 ]

With the latest support for the MyISAM-Engine merging this pull request would save some trouble.

Background/Steps to reproduce:
If you have 2 entities with guid/uuid as primary key, @ManyToMany/@JoinTable fails on MyISAM, because it would create a jointable with 2 VARCHAR(255) columns and would apply a combined primary key on these two columns. But MyISAM doesn't support keys longer than 1000 bytes so you can't create the jointable.

See: https://dev.mysql.com/doc/refman/5.6/en/myisam-storage-engine.html

The maximum key length is 1000 bytes. This can also be changed by changing the source and recompiling. For the case of a key longer than 250 bytes, a larger key block size than the default of 1024 bytes is used.

In my opinion this isn't just a "minor" issue but a major because some people can't run on MySQL with InnoDB for some reason.

Comment by Marco Pivetta [ 28/Feb/14 ]

Michael Kühn MyISAM is niche support for the ORM - using a custom type is perfectly fine in such a case.

Comment by Michael Kühn [ 04/Mar/14 ]

Marco Pivetta I agree, but i don't see why we would assume a GUID/UUID - which is per definition 36 chars long - as a 255 char long string. It would save storage space (for platforms don't supporting a native uuid type) and circle around at least 1 barrier if using MyISAM.

By the way, the PR is missing something. While it works perfectly fine the first time, every orm:schema-tool:update would output the guid-columns every time if you don't specifiy "length=36" and "fixed=true" on every GUID-@Column. IMHO the GUID-Type should implicit this both attributes in this pull request so you don't get column updates that don't change anything.

Comment by Steve Müller [ 08/Mar/14 ]

Michael Kühn I get your point and thanks for pointing out the remaining issue. The problem is caused by the comparator which detects differences in the column definition because the length and fixed attribute are hardcoded in the platform which is beyond comparator's knowledge. Still I think this can be fixed easily but as long as Benjamin Eberlei is of the opinion that this change is a minor BC break, this PR won't make it into the master branch.





[DBAL-372] Add SQL parser Created: 25/Oct/12  Updated: 25/Oct/12

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

Type: New Feature Priority: Minor
Reporter: Martin Hasoň Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

It is useful for create sql highlighter. See https://github.com/doctrine/DoctrineBundle/pull/117 or https://github.com/doctrine/DoctrineBundle/issues/107






[DBAL-319] Doctrine\DBAL\Types\Type Created: 12/Aug/12  Updated: 22/Dec/13

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

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


 Description   

The API could be improved in the next major release:

  • Type::add() instead of addType()
  • Type::isRegistered() instead of hasType() (has sounds weird)

Etc.. I think the 'type' in the methods is redundant since Type is already the object I am dealing with.

I'd also like a remove() method to unregister a type at runtime. Would make testing a little easier and I don't have to check with hasType() etc..



 Comments   
Comment by Marco Pivetta [ 12/Aug/12 ]

I don't think those namings are really important.
There's one major change to do, which is to somehow get rid of the staticness of the `Doctrine\DBAL\Types\Type` class, and it is not a simple task.
It would also be interesting to set the type objects manually, such as a database `password` type that does encryption/decryption based on a given service. That cannot be done without staticness right now, which renders two different connections requiring the same functionality but with different parameters very difficult.

Comment by Till [ 12/Aug/12 ]

I agree on the static. But I'd also like the API to be cleaned up and the remove method.

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

API cleanup and staticness can be addressed in 3.0 for the first time. Otherwise we cannot keep BC. You can use Doctrine\DBAL\Types\Type::overrideType('someType', null); as a workaround for removing a type from the registry.





[DBAL-292] Multiple use of named parameter doesn't work Created: 12/Jun/12  Updated: 28/Dec/13

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

Type: Bug Priority: Minor
Reporter: Jürgen Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

IIS 7.5, MS-SQL-Server 2005, PHP 5.4.0



 Description   

In the example in the documentation http://doctrine-dbal.readthedocs.org/en/2.0.x/reference/data-retrieval-and-manipulation.html#dynamic-parameters-and-prepared-statements there is the following example:

$sql = "SELECT * FROM users WHERE name = :name OR username = :name";
$stmt = $conn->prepare($sql);
$stmt->bindValue("name", $name);
$stmt->execute();

When I try this example using pdo_sqlsrv I get the following error:
PDOException: SQLSTATE[07002]: [Microsoft][SQL Server Native Client 11.0]COUNT field incorrect or syntax error

When I use instead the parameters name1 and name2 the query works as expected.



 Comments   
Comment by Alexander [ 07/Jul/12 ]

Are you sure you were using the 2.2.2 version of the ORM? Can you try to reproduce this with the latest master?

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

Jürgen ping. I cannot reproduce this error, either. Can you please try to reproduce this with the latest master branch? Otherwise I will close this ticket.





[DBAL-180] Documentation states that Doctrine 'decimal' (DecimalType) is mapped to PHP 'double', however, string is returned Created: 11/Nov/11  Updated: 28/Dec/13

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

Type: Documentation Priority: Minor
Reporter: Menno Holtkamp Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

At http://www.doctrine-project.org/docs/orm/2.1/en/reference/basic-mapping.html#doctrine-mapping-types, it is stated that:

"decimal: Type that maps an SQL DECIMAL to a PHP double."

However, in the commit history, we can see that the casting to a float is removed: https://github.com/doctrine/dbal/commits/master/lib/Doctrine/DBAL/Types/DecimalType.php. Casting to a double is not possible in PHP?This seems to result in a float as well, that is probably why it was removed.

I found this out when using PHP's 'is_double()' function (alias of is_float()) to check whether a decimal property was set or not.

Suggestion is to either:

  • cast to a double (which seems not possible)
  • cast to a float (why was this removed?)
  • do nothing to the code, update documentation that string is returned.

In my check function I guess I will use the is_numeric() function.



 Comments   
Comment by Roel Harbers [ 19/Mar/12 ]

I would strongly suggest to leave the behaviour as-is, and fix the documentation, because of all the trouble associated with floating point and rounding. People use the DECIMAL type to prevent those issues, so having the ORM convert it to floating point again would be pretty bad.

Comment by Patrick McDougle [ 26/Apr/12 ]

I have submitted a pull request on this issue on github. Hopefully the doc will be updated soon so other people don't expect the wrong behavior!

https://github.com/doctrine/orm-documentation/pull/93

Mods, this issue can probably be closed.

Comment by Oleg Namaka [ 24/May/12 ]

Leaving decimal values as strings creates another issue with unnecessary entity updates because old and new same values have different types: old value is always the string type, the new one - decimal. If an old value is '10.00' as a string and the new value is 10 decimal than Doctrine will issue the UPDATE statement for that entity. This is plainly wrong IMHO.

Comment by karlie verkest [ 20/Dec/12 ]

There may be other issues around comparison. I'd rather be comparing numeric types than strings when comparing "decimal" values.

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

I don't think we can fix this in DBAL. We should leave the decimal values retrieved from database as string for the obvious conversion problems. AFAIK the documentation in ORM has also been updated. Don't know about ORM issues with entity updates, but I don't see any further todo here in DBAL. Can this ticket be closed?

Comment by Oleg Namaka [ 28/Dec/13 ]

@Steve Muller, is it feasible to change the way decimal values are compared from strict === to == to mitigate the issue with unnecessary updates:

If an old value is '10.00' as a string and the new value is 10 decimal than Doctrine will issue the UPDATE statement for that entity.

This is a very serious Doctrine shortcoming as for every single entity that has at least one decimal field with no real value changes updates still will be issued.

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

Oleg Namaka I understand that. But IMO this is an issue that has to be adressed in ORM because casting the values in the DBAL type breaks the precision/correctness of the original database value in some circumstances. Therefore the only possible solution can be to fix this in ORM IMO.





[DBAL-179] SQLLogger API improvement: log rows affected Created: 10/Nov/11  Updated: 10/Nov/11

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

Type: Improvement Priority: Minor
Reporter: Howard Ha Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

A small suggestion. It is useful in our application to log the affected rows in queries in order to make it easier to trace what queries did what. I think a simple way to enable this in the SQLLogger is to modify the stopQuery() interface to receive an option rowcount parameter.






[DBAL-150] noSQL Shema Management Created: 21/Aug/11  Updated: 21/Aug/11

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

Type: New Feature Priority: Minor
Reporter: Alexey Shatunov Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

all



 Description   

I have a few ideas to improve DBAL and ORM management for php:
1. Reading if needed ORM schemas definitions from YAML(existing plugin)
2. Then migration it into the one of NoSQL databases(such as MongoDB or Memcache/MemcacheDB)
3. Creating transactional temporary-changes data layer in NoSQL for a current-changes due the webapp launch and running for each run
4. Periodically migrations of a current changes with migration script into RDB(for example by cron)

So we get:
Fast automatic shemas management(Symphony users - I say you "haha" because you have to do some unuseful things like "doctrine:build-schema" etc)
All advantages of RDB (like JOINS) in a data extraction
Full-independence in data changing due to webapp launch(and no transactions are needed) in the current NoSQL data-layer
Low load to the server because after extration we have a lazy return data into the RDB
In feature a simple caching any fast-changed data into NoSQL

What do you thinking about it?






Generated at Thu Apr 24 14:01:52 UTC 2014 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.