[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-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`") */




Generated at Sat Aug 29 23:37:55 EDT 2015 using JIRA 6.4.10#64025-sha1:5b8b74079161cd76a20ab66dda52747ee6701bd6.