[DBAL-700] [GH-441] Fixed renaming of MSSQL columns Created: 09/Dec/13  Updated: 17/Dec/13  Resolved: 17/Dec/13

Status: Closed
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: Invalid Votes: 0
Labels: None


 Description   

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

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

Message:

Column renaming supports tables with same name in multiple schemas



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

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





[DBAL-481] [GH-297] check for proper type when formatting dates Created: 02/Apr/13  Updated: 02/Apr/13  Resolved: 02/Apr/13

Status: Closed
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: Invalid Votes: 0
Labels: None


 Description   

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

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

Message:



 Comments   
Comment by Benjamin Eberlei [ 02/Apr/13 ]

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





[DBAL-465] [GH-286] Fix data not being cached in ResultCache Created: 19/Mar/13  Updated: 20/Mar/13  Resolved: 20/Mar/13

Status: Closed
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: Invalid Votes: 0
Labels: None


 Description   

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

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

Message:

The ResultCacheStatement has a small logic error, it tested for emptied
being true when it should have tested for emptied being false. The
comments also statement that the function returns a boolean, however the
function didn't return a boolean.

This is my first time committing to a larger open source project like dbal. Very worried I'll of done something wrong, please go easy / teach me.



 Comments   
Comment by Benjamin Eberlei [ 20/Mar/13 ]

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

Comment by Benjamin Eberlei [ 20/Mar/13 ]

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

Comment by Benjamin Eberlei [ 20/Mar/13 ]

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





[DBAL-456] [GH-279] adds new output format Created: 03/Mar/13  Updated: 05/Mar/13  Resolved: 05/Mar/13

Status: Closed
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: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: None


 Description   

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

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

Message:

The output of the ::dump command is very unstable (depends on platform/PHP version/installed extensions).

This pull request adds a new format which is more suitable for machine consumption.



 Comments   
Comment by Benjamin Eberlei [ 04/Mar/13 ]

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





[DBAL-454] [GH-277] Remove duplicate SQL parts in query generation Created: 02/Mar/13  Updated: 20/Aug/13  Resolved: 03/Mar/13

Status: Closed
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: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: None


 Description   

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

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

Message:

Presently, it's possible to do this using QueryBuilder:

```php
$qb->select('u.*')
->from('users', 'u')
->addOrderBy('u.name', 'ASC')
->addOrderBy('u.name', 'ASC'); // duplicate
```
Which produces:
```sql
SELECT u.* FROM users u ORDER BY u.name ASC, u.name ASC
```

This patch removes duplicates from the `SELECT`, `SET`, `ORDER BY` and `GROUP BY` parts during SQL generation (there's already logic that removes duplicate `FROM` parts).

I've added test cases for each affected keyword as well.



 Comments   
Comment by Benjamin Eberlei [ 03/Mar/13 ]

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

Comment by Doctrine Bot [ 20/Aug/13 ]

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





[DBAL-426] [GH-256] Create queryBuilder from parts. Created: 25/Jan/13  Updated: 26/Jan/13  Resolved: 26/Jan/13

Status: Closed
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: Invalid Votes: 0
Labels: None


 Description   

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

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

Message:

Add a feature that can create a queryBuilder from queryBuilder parts.

This can be used when a query is build and needs to be stored somehow and restore it later.



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

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





[DBAL-414] zaza Created: 09/Jan/13  Updated: 09/Jan/13  Resolved: 09/Jan/13

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

Type: Bug Priority: Major
Reporter: batbileg Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None
Environment:

aaan



 Description   

yu



 Comments   
Comment by batbileg [ 09/Jan/13 ]

yu wm





[DBAL-391] [GH-233] convertToPHPValue should match convertToDatabaseValue Created: 23/Nov/12  Updated: 03/Dec/13  Resolved: 23/Nov/12

Status: Closed
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: Invalid Votes: 0
Labels: None


 Description   

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

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

Message:

convertToPHPValue return resource which is not match default convertToDatabaseValue that not make and change. Change to return content of the resource.



 Comments   
Comment by Marco Pivetta [ 23/Nov/12 ]

Blob field types should be converted to resources:
https://travis-ci.org/doctrine/dbal/jobs/3329007/#L77

Comment by Benjamin Eberlei [ 26/Nov/12 ]

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

Comment by Doctrine Bot [ 03/Dec/13 ]

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





[DBAL-376] [GH-223] Include customSchemaOptions in column mapping Created: 05/Nov/12  Updated: 14/Jan/13  Resolved: 14/Jan/13

Status: Closed
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: Duplicate Votes: 0
Labels: None


 Description   

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

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

Message:

This PR adds the customSchemaOptions in the array passed to the type.



 Comments   
Comment by Marco Pivetta [ 14/Jan/13 ]

Solved in DBAL-413





[DBAL-368] array and object types should use BLOB, not CLOB, to store serialized data Created: 19/Oct/12  Updated: 20/Dec/13  Resolved: 23/Jan/13

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

Type: Bug Priority: Major
Reporter: Karsten Dambekalns Assignee: Benjamin Eberlei
Resolution: Duplicate Votes: 0
Labels: postgresql


 Description   

When using array or object types, PHP's serialize() is used. Since that can return NUL bytes, using a text type will fail at least on PostgreSQL (just search the web for issues of that kind…).

So ArrayType and ObjectType should return a BLOB definition instead of a CLOB definition to be binary-safe.



 Comments   
Comment by Karsten Dambekalns [ 19/Oct/12 ]

See DBAL-369 for the suggested fix

Comment by Marco Pivetta [ 23/Jan/13 ]

Karsten Dambekalns DBAL-368 is this issue. What's the one you were referring to?

Comment by Marco Pivetta [ 23/Jan/13 ]

Nvm, it was DBAL-369

Comment by Marco Pivetta [ 23/Jan/13 ]

Moved to DBAL-369

Comment by Doctrine Bot [ 20/Dec/13 ]

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





[DBAL-333] [GH-193] Add DBAL\TypeAwareObject. Created: 29/Aug/12  Updated: 20/Nov/13  Resolved: 20/Nov/13

Status: Closed
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: Invalid Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of Romain-Geissler:

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

Message:

This PR adds a common interface for custom object values that requires some PHP <-> SQL conversions, which allows to specify what DBAL type must be used for conversion.



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

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





[DBAL-327] [GH-188] Akiban driver Created: 24/Aug/12  Updated: 20/Nov/13  Resolved: 20/Nov/13

Status: Closed
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: Invalid Votes: 0
Labels: None


 Description   

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

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

Message:

An initial implementation of a driver for the [Akiban Server](http://www.akiban.com/akiban-server). You will notice in the diff there are some features Akiban does not yet support in its latest release but are planned for future releases.

I wasn't sure if pull request was the best way to start a dialog to get this work accepted or whether the mailing list is more appropriate. Please let me know and I will do as suggested.

I am an engineer at Akiban and am very willing to maintain/improve this driver.



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

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

Comment by Padraig O'Sullivan [ 28/Aug/12 ]

Yes, this ticket has been superseded by ticket 330.





[DBAL-308] [GH-174] Used the placeholder in the command help for the name Created: 16/Jul/12  Updated: 23/Jul/12  Resolved: 23/Jul/12

Status: Closed
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: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

This change will allow to keep the original help message in DoctrineBundle even if we rename the command. I will submit the same PR for the ORM.

@beberlei please include it in the 2.3 branch (and ideally in 2.2 if it is not too much to ask for it). My goal is to stop duplicating the help messages in the bundle as outdated help messages are really a pain for users (see doctrine/DoctrineBundle#89)



 Comments   
Comment by Benjamin Eberlei [ 23/Jul/12 ]

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





[DBAL-291] [GH-157] interface compatibility Created: 01/Jun/12  Updated: 21/Nov/13  Resolved: 21/Nov/13

Status: Closed
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: Invalid Votes: 0
Labels: None


 Description   

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

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

Message:






[DBAL-260] [GH-135] Add typehint info to core types for use by entity generator. Created: 18/Apr/12  Updated: 04/May/12  Resolved: 04/May/12

Status: Closed
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: Invalid Votes: 0
Labels: None


 Description   

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

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

Message:

So as you probably know, the EntityGenerator doesn't typehint the setters for the DateTime types (datetime, date, datetimetz, time) - which has just caused me to miss an obvious error, and judging from google, plenty of others before me too.

So I've added it - you'll have a pull request in a sec on the doctrine2 repo for that, but it needs this change too - which provides the mapping info.



 Comments   
Comment by Benjamin Eberlei [ 26/Apr/12 ]

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





[DBAL-258] [GH-133] Removed Paranthesis to allow for more complex Regex Created: 17/Apr/12  Updated: 04/May/12  Resolved: 04/May/12

Status: Closed
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: Invalid Votes: 0
Labels: None


 Description   

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

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

Message:

Needed to remove the Paranthesis to allow excluding of Tables with more complex Regular Expressions.



 Comments   
Comment by Benjamin Eberlei [ 17/Apr/12 ]

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





[DBAL-253] [GH-132] Added Support for excluding Tables Created: 10/Apr/12  Updated: 04/May/12  Resolved: 04/May/12

Status: Closed
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: Invalid Votes: 0
Labels: None


 Description   

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

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

Message:



 Comments   
Comment by Benjamin Eberlei [ 18/Apr/12 ]

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





[DBAL-246] [GH-125] PHPDoc blocks improvments + 1 CS Fix Created: 02/Apr/12  Updated: 04/May/12  Resolved: 04/May/12

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

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

Message:

Hey guys,

I started to fix a class type inside Connection and then i went ahead to see what i could also improve!

Adrien



 Comments   
Comment by Benjamin Eberlei [ 02/Apr/12 ]

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

Comment by Benjamin Eberlei [ 03/Apr/12 ]

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





[DBAL-226] DATETIME2 in MSSQL - declared, but not supported Created: 20/Feb/12  Updated: 05/Mar/12  Resolved: 05/Mar/12

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

Type: Bug Priority: Major
Reporter: ross neacoders Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None


 Description   

From Doctrine documentation

27. Limitations and Known Issues
...
27.2.2. Microsoft SQL Server and Doctrine "datetime"
Doctrine assumes that you use DateTime2 data-types. If your legacy database contains DateTime datatypes then you have to add your own data-type (see Basic Mapping for an example).

In reality, the type is not supported, failing with exception

Could not convert database value "2012-02-15 01:25:12.0000000" to Doctrine Type datetime. Expected format: Y-m-d H:i:s.u

The reason of such behavior is a bug in DBAL
MsSQLPlatform::getDateTimeFormatString => 'Y-m-d H:i:s.u'

u (milliseconds in PHP) occupy 6 digits, while datetime2 type has 7 digits.
The solution is to truncate last digit before conversion



 Comments   
Comment by Benjamin Eberlei [ 03/Mar/12 ]

cCtually it is supported, when the DATETIME2 are created through Doctrine, because it makes DATETIME2(6) out of them to make DateTime#createFromFormat() support work. I am not sure how to fix this problem with "datetime" type, it will work when you use the VarDateTime types, these are a bit slower, but dont have this problem. Just call this in your bootstrap:

\Doctrine\DBAL\Types\Type::overrideType("datetime", "Doctrine\DBAL\Types\Type\VarDateTime");
Comment by ross neacoders [ 05/Mar/12 ]

Beberlei,

This issue is related to datetime2 MSSQL type (NOT datetime MSSQL type).

Datetime2 is declared, but not supported - read above again.

Comment by Benjamin Eberlei [ 05/Mar/12 ]

I read your comment and did speak about DATETIME2.

DATETIME in MsSQL only has 3 digits after the second. DATETIME2 by default has 7. However PHPs DateTime#createFromFormat() only supports 6 digits. That is why Doctrine creates MsSQL DATETIME2(6) columns, restricting to 6 digits. If your database already has DAteTime2 columns with 7 digits, then you have to register the VarDateTime type as detailed in my comment above.

Comment by ross neacoders [ 05/Mar/12 ]

Understand, you mentioned "datetime" in your post, so I thought you misunderstood the issue.

But, isn't checking if DATETIME2 is (7) and truncating last digit not a better option, if VarDateTime and date_create have bad speed?
VarDateTime seems to work, but last 7th digit is not considered anyway.
Also this will eliminate need to change something in bootstrap.





[DBAL-159] Symfony Doctrine Task "doctrine:database:create" fails with "Undefined index: dbname" Created: 25/Aug/11  Updated: 30/Oct/11  Resolved: 30/Oct/11

Status: Closed
Project: Doctrine DBAL
Component/s: Drivers
Affects Version/s: 2.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ed Anderson Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None
Environment:

Symfony 2.0, Doctrine 2.1, PHP 5.3.8 and Oracle 11g-R2 Enterprise



 Description   

For some reason,when attempting to create a database, the doctrine:database:create task fails complaining that the "dbname" parameter is not found. Printing the $params var from the file "vendor/doctrine-dbal/lib/Doctrine/DBAL/Driver/PDOOracle/Driver.php" indeed shows that the dbname array element is not present. However, it is present in the app/config/parameters.ini (as database_name).

The following is the method from PDOOracle/Driver.php where the missing "dbname" index is used a few times... adding the dbname with an appropriate value
allows the dsn to get created - but Oracle then throws an ORA-00911 error indicating an invalid character in the PDO statement... However, I'm able to use the output of _constructPdoDsn( ) in a simple standalone connect script (provided below) successfully.

    private function _constructPdoDsn(array $params)
    {
        $params['dbname'] = 'pmdb0';  // Inserted for testing by Ed Anderson
        $dsn = 'oci:';
        if (isset($params['host'])) {
            $dsn .= 'dbname=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)' .
                   '(HOST=' . $params['host'] . ')';

            if (isset($params['port'])) {
                $dsn .= '(PORT=' . $params['port'] . ')';
            } else {
                $dsn .= '(PORT=1521)';
            }

            $dsn .= '))(CONNECT_DATA=(SERVICE_NAME=' . $params['dbname'] . ')))';
        } else {
            $dsn .= 'dbname=' . $params['dbname'];
        }

        if (isset($params['charset'])) {
            $dsn .= ';charset=' . $params['charset'];
        }

        print( $dsn ); // Inserted to extract the constructed DSN and test in an external php script...
        return $dsn;
    }

-------- Script created using the output of _constructPdoDsn( ) follows ----- This script works fine...

$dsn = 'oci:dbname=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=pmdb0.mydomain.net)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=pmdb0)));charset=UTF8';
$user = 'pmcore';
$pass = 'mypaswd';

try
{
    $dbh = new PDO( $dsn, $user, $pass );

    if( $dbh )
    {
        print( "Connected to PDO using: " . $dsn . "\n");
        unset( $dbh );
    }
}

catch( PDOException $e )
{
    print( "ERROR: " . $e->getMessage( ) );
    die( );
}

---------------- End Test Script -------------



 Comments   
Comment by Ed Anderson [ 25/Aug/11 ]

Running the task doctrine:schema:create --dump-sql produces output that will correctly build the tables in the database manually... but this is not ideal obviously. Still can't seem to find where the "invalid character" is showing in the statement generated by the PDOOracle Driver or some other file in the DBAL.

Comment by Guilherme Blanco [ 17/Sep/11 ]

Formatted ticket

Comment by Benjamin Eberlei [ 30/Oct/11 ]

I would advise against using the PDO Oracle driver, as PDO Oracle has bugs and it is not maintained anymore, not even by Oracle. OCI8 is the way to go.

Also creating a database is not supported in Oracle, since there is no concept database.

Comment by Benjamin Eberlei [ 30/Oct/11 ]

The parameter name has to be "dbname" in symfony also.





[DBAL-156] Github-PR-44 by richardfullmer: [PostgresPlatform] Fixing change detection when a default is removed Created: 21/Aug/11  Updated: 20/Nov/13  Resolved: 20/Nov/13

Status: Closed
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: Invalid Votes: 0
Labels: None


 Description   

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

{username}

:

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

Message:

Change detection when the default value is removed from a field is presently broken and produces invalid SQL.

This patch checks to see if a new default value actually exists before adding the SET DEFAULT '';

Uses DROP DEFAULT when the new default value does not exist






[DBAL-155] Github-PR-46 by gnomii: 2.1.x PgSql - Same problem with the master Created: 21/Aug/11  Updated: 20/Nov/13  Resolved: 20/Nov/13

Status: Closed
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: Invalid Votes: 0
Labels: None


 Description   

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

{username}

:

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

Message:

Hi,

Sorry, I was not able to merge the branchs with the master I try some methods

Best regards,
Maxime



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

PR was closed





[DBAL-154] Github-PR-47 by gnomii: 2.0.x PgSql - Same problem with the master Created: 21/Aug/11  Updated: 20/Nov/13  Resolved: 20/Nov/13

Status: Closed
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: Invalid Votes: 0
Labels: None


 Description   

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

{username}

:

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

Message:

Hi,

Sorry, I was not able to merge the branchs with the master I try some methods

Best regards,
Maxime






[DBAL-77] Mysql Numeric / Decimal fields Created: 13/Dec/10  Updated: 04/Jan/13  Resolved: 15/Mar/12

Status: Closed
Project: Doctrine DBAL
Component/s: None
Affects Version/s: 2.0.0-BETA4, 2.0, 2.0.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Eugene Assignee: Benjamin Eberlei
Resolution: Can't Fix Votes: 2
Labels: None
Environment:

mysql 5.1.49 for debian-linux-gnu (x86_64), Ubuntu 10.10 Doctrine DBAL Beta4 Doctrine ORM Beta4 Doctrine Common RC1



 Description   

class product {
/**
*Column(type="decimal", scale="2")
*
*/
private $discount;
}

generate SQL

create table product {
discount DECIMAL(10,2) NOT NULL
}

if you have a field in a database type DECIMAL doctrine tries to
generate for him diff

doctrine orm:schema-tool
>
ALTER TABLE product CHANGE discrount discrount NUMERIC (10, 2) NOT NULL

but mysql ignore the alter, as a result of these diff stretch from
migration to migration



 Comments   
Comment by Benjamin Eberlei [ 13/Dec/10 ]

This is fixed in RC1 or RC2.

Comment by Eugene [ 20/Jan/11 ]

checked for the version of doctrine 2.1.0-DEV
result is the same

Comment by Oleg Anashkin [ 31/Jan/11 ]

I have the same issue with the latest doctrine build. Please fix it because it makes schema migration scripts dirty with redundant changes.

Comment by Benjamin Eberlei [ 04/Mar/11 ]

I cannot reproduce this, does this happen if you also specify precision=10 ?

Comment by Alexander [ 15/Mar/12 ]

Closing until someone can provide more feedback.

Comment by Joel Simpson [ 04/Jan/13 ]

I am seeing this bug for a definition specified as:

  • @ORM\Column(type="decimal", precision=20, scale=0, nullable=false, unique=true)

Doctrine Command Line Interface version 2.3.2-DEV





[DBAL-48] Doctrine\DBAL\Platforms\MsSqlPlatform Incorrect Offset Limit Sql Created: 04/Sep/10  Updated: 14/Nov/10  Resolved: 14/Nov/10

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

Type: Bug Priority: Major
Reporter: Scott Connelly Assignee: Juozas Kaziukenas
Resolution: Invalid Votes: 0
Labels: None
Environment:

All MSSQL



 Description   

The way the offset query is constructed (line 473) it always pulls the top records from the query even when and offset is present, so if you have an offset of 0 and limit of 10 you get the first 10 records. When you change the offset to 5 you still get the first 10 records from the original query. This issue was also in the 1.2 driver code.

This is basically what gets created when an offset is present with a limit of 10 and an offset of 5 :
SELECT * FROM
(SELECT TOP 10 * FROM
(SELECT TOP 15
col1, col2, colN FROM table
) AS [inner_tbl]
) AS [outer_tbl]

The fix is to reconstruct the query to remove the outer_tbl SELECT TOP and make it something like the following:
SELECT * FROM (
SELECT TOP [limit] ROW_NUMBER() OVER (ORDER BY [primary_key]) as RowNum, col1, col2, colN FROM table
) as [inner_tbl] WHERE [inner_tbl].RowNum BETWEEN [offset] AND [limit + offset]



 Comments   
Comment by Juozas Kaziukenas [ 14/Nov/10 ]

This is fixed in current master https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Platforms/MsSqlPlatform.php#L555

Unless this ticket is referring to Doctrine 1





[DBAL-332] Memory option for Sqlite driver does nothing Created: 29/Aug/12  Updated: 04/Jun/14  Resolved: 17/Sep/12

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

Type: Bug Priority: Major
Reporter: Damien ALEXANDRE Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None
Environment:

PHP Version 5.3.10
SQLite Library 3.7.9
Doctrine 2.3.x-dev
Dbal 2.3.x-dev
Symfony 2.1 RC2



 Description   

I'm trying to configure a "memory" sqlite database, as described here: http://docs.doctrine-project.org/projects/doctrine-dbal/en/latest/reference/configuration.html#pdo-sqlite

So here is my configuration (config_test.yml) :

Unable to find source-code formatter for language: yml. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml
 
doctrine:
    dbal:
        driver:    pdo_sqlite
        memory:    true
        user:      db_user
        password:  db_pwd
        charset:   UTF8

I'm then running

./app/console doctrine:database:create --env=test

and the result is a "myBdName" db file (the filename contains the quote!!) in my root folder.

I don't understand why the file http://www.doctrine-project.org/api/dbal/2.3/source-class-Doctrine.DBAL.Schema.SqliteSchemaManager.html#46 is creating a path option with my DB name, if I comment the line 57, everything seems fine (no more file created).

I have seen some memory related options in the Doctrine test suite so maybe I'm doing it wrong, and in that case that's a documentation issue I can work on.

Thx,
Damien



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

You cannot create an in memory database using Symfonys database:create. The in memory database will be closed when the request ends. So its completly useless this way. You have to recreate it in every request that you want to use it. It is just good for one request.

Comment by Damien ALEXANDRE [ 06/Sep/12 ]

My example with "app/console" is misleading,
what I want to do is building a memory SQLite database on the fly and run some code right after it (in a phpunit test).

The issue here is that there is an option documented (first link) that doesn't work / is not implemented (second link). And a physic file is generated, it should not.

As your answer seems to be based on the mistaken impression that I wanted to use volatile database in a persistent way, I'm reopening this issue.

Thanks for your time.
Damien.

Comment by Benjamin Eberlei [ 07/Sep/12 ]

Try removing the user/password keys. memory database connection works for me, this seems to be a configuration issue.

If you want to create an in memory db for testing then you have to create the schema with SchemaTool inside the phpunit tests.

Comment by Benjamin Eberlei [ 17/Sep/12 ]

No feedback on potential fix, this issue is either misconfiguration or wrong use of the API. I couldn't reproduce this and it works for me (TM).

Comment by Iain Potter [ 04/Jun/14 ]

Hi guys, this does not work for me either. Same use case.

Config:

driver: pdo_sqlite
memory: true

Comment by Iain Potter [ 04/Jun/14 ]

Apologies for resurrecting an old issue but a google search brought me here.





[DBAL-921] [GH-616] Always store dates in UTC Created: 11/Jun/14  Updated: 26/Jun/14  Resolved: 26/Jun/14

Status: Closed
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: Won't Fix Votes: 0
Labels: None


 Description   

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

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

Message:

This PQ will make sure that the dates saved in the database (without indication of timezone) is always stored in the UTC timezone.

I was doing development on my machine in Sweden when I noticed that when I created a `DateTime`, stored it in the db and then retrieved it again, the time was off by two hours. This is because a created the `DateTime` object with the UTC timezone. Doctrine then saved it straight to the database (by using `$date->format(...)`) and thus the information about which timezone it was in was lost. When doctrine then fetched the value, it used `DateTime::createFromFormat(...)` to create a `DateTime` for me. The problem is that since the timezone wasn't saved anywhere, it assumed that it was a Swedish date, and thus it removed two hours.

I believe that the correct way of doing it is to store the dates in the db as UTC. Then it will always work no matter what the default timezone is, even if I later decide to change it.

`date_default_timezone_set('UTC')` is not the answer. If I use it, I need to make sure that every `DateTime` that I pass to doctrine always has the timezone set to `UTC`. Since the `DateTime` can come from any number of sources (e.g. third party library) it could easily introduce hard to detect bugs. It will also output every date in the UTC timezone which may not be what I want if I'm developing a localised site (e.g. small page for a local Swedish business).



 Comments   
Comment by Doctrine Bot [ 26/Jun/14 ]

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





[DBAL-704] [GH-444] DBAL-669 - Update SQL for generated by the schema tool will also create schemas Created: 13/Dec/13  Updated: 21/Aug/14  Resolved: 13/Dec/13

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

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


 Description   

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

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

Message:

DBAL-669 - Updating a schema should introduce also schema creation statements in the generated SQL



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

Duplicate of DBAL-669

Comment by Doctrine Bot [ 22/Dec/13 ]

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

Comment by Doctrine Bot [ 22/Dec/13 ]

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

Comment by Doctrine Bot [ 21/Aug/14 ]

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





[DBAL-471] when persisting objects to Doctrine2 and one of the tables are named the same as a MySQL reserved word Created: 24/Mar/13  Updated: 24/Mar/13  Resolved: 24/Mar/13

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

Type: Improvement Priority: Minor
Reporter: Per-Øivin Berg Andersen Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: None
Environment:

MySQL on Ubuntu



 Description   

I am not sure this is a correct posting to your issue tracker, as I am a beginner at development, at least in the sense of doctrine.

I have an entity named Trigger in my Symfony2 project. I had set the table name to be "trigger", and this did not work. However, the entities were created without any problems, I first discovered the problem when attempting to persist a Trigger entity. The solution was to rename the table to "mtrigger" or something else, but I think the error message could be better somehow. Now it throws an exception with the MySQL error, which only says there's an error in the syntax, and to check the manual. The manual is quite huge and it was a horror for me before I started thinking in the field of reserved words.

Note that this is just a proposal to an improvement. It might be that it is hard to implement it for you. In that case, please just close the issue.



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

Doctrine 2 ORM allows you to define "naming strategies" and/or to quote the table names with mysql-style ticks that get automatically quoted, like:

/** @ORM\Table(name="`foo`") */




[DBAL-353] doctrine:schema:update doesn't understand it doesn't need to run again Created: 25/Sep/12  Updated: 23/Jan/13  Resolved: 23/Jan/13

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

Type: Bug Priority: Minor
Reporter: Mark A. Hershberger Assignee: Marco Pivetta
Resolution: Incomplete Votes: 0
Labels: None


 Description   

doctrine:schema:update keeps thinking there is more to do:

$ php app/console doctrine:schema:update --dump-sql
ALTER TABLE Account CHANGE guid guid VARCHAR(255) NOT NULL;
ALTER TABLE Customer CHANGE guid guid VARCHAR(255) NOT NULL, CHANGE authGuid authGuid VARCHAR(255) NOT NULL
$ php app/console doctrine:schema:update --force   
Updating database schema...
Database schema updated successfully! "2" queries were executed
$ php app/console doctrine:schema:update --dump-sql
ALTER TABLE Account CHANGE guid guid VARCHAR(255) NOT NULL;
ALTER TABLE Customer CHANGE guid guid VARCHAR(255) NOT NULL, CHANGE authGuid authGuid VARCHAR(255) NOT NULL


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

Can you paste your ORM mapping for these fields ?

Comment by John Robeson [ 01/Nov/12 ]

I had the same problem. I used doctrine:mapping:import
to bootstrap some entities. It generated my
session entity primary key with a GeneratedValue strategy of
IDENTITY when it should have been NONE.

This sounds like the same problem with the string key
and incorrect GeneratedValue strategy.

PS: I ran into that doctrine:mapping:import issue
perhaps a year ago, when i first started playing with doctrine.
I do not know if it still persists.





[DBAL-358] This issue should be removed. Wrong merge on github. Created: 04/Oct/12  Updated: 03/Dec/13  Resolved: 23/Jan/13

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

Type: Bug Priority: Trivial
Reporter: Benjamin Eberlei Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: None


 Description   

This issue should be removed. Wrong merge on github.



 Comments   
Comment by Benjamin Eberlei [ 04/Oct/12 ]

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

Comment by Doctrine Bot [ 03/Dec/13 ]

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





Generated at Tue Nov 25 20:56:46 UTC 2014 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.