[DBAL-60] OCI8Connection couldn't connect when charset parameter specified Created: 09/Nov/10  Updated: 29/Dec/12  Resolved: 11/Nov/10

Status: Resolved
Project: Doctrine DBAL
Component/s: Drivers
Affects Version/s: 2.0.0-BETA4
Fix Version/s: 2.0.0-RC1-RC3

Type: Bug Priority: Major
Reporter: Miloslav "adrive" Kmet Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None
Environment:

PHP Version 5.3.3-1ubuntu9, OCI8 1.4.1, Oracle 10.2.0.4.0



 Description   

When I am trying to connect to Oracle instance with another charset then specified in my environment variable NLS_LANG I got an error.

$connectionOptions['oracle'] = array(
    'driver' => 'oci8',
    'dbname' => 'BOOK',
    'user' => 'doctrine',
    'password' => 'doctrine',
    'charset' => 'AL32UTF8',
);

$em = EntityManager::create($connectionOptions['oracle'], $config, $evm);
$em->getConnection()->connect();

Produce error messages:

PHP Warning: oci_error() expects parameter 1 to be resource, boolean given in /www/test/doctrine2/vendor/dbal/lib/Doctrine/DBAL/Driver/OCI8/OCI8Connection.php on line 149
PHP Fatal error: Uncaught exception 'Doctrine\DBAL\Driver\OCI8\OCI8Exception' in /www/test/doctrine2/vendor/dbal/lib/Doctrine/DBAL/Driver/OCI8/OCI8Connection.php:42

There is bug in OCI8Connection::errorInfo() and ::errorCode(). When oci_connect failed, it returns a boolean - false. but oci_error() accepts only resource as parameter. Therefor it is neccessary to check, whether $this->_dbh is resource.

When I've fixed the error handling, I've got the right error, why I couldn't connect to Oracle:

PHP Fatal error: Uncaught exception 'Doctrine\DBAL\Driver\OCI8\OCI8Exception' with message 'ORA-12154: TNS:could not resolve the connect identifier specified' in /www/test/doctrine2/vendor/dbal/lib/Doctrine/DBAL/Driver/OCI8/OCI8Exception.php:28

That's because oci_connect accepts as connection string only TNS name, or Oracle Connection string. But ;charset=* in TNS name or connection string is invalid. oci_connect has 4th parameter charset for that purpose.



 Comments   
Comment by Miloslav "adrive" Kmet [ 09/Nov/10 ]

Fixed in https://github.com/milokmet/dbal/tree/DBAL-60

Comment by Benjamin Eberlei [ 11/Nov/10 ]

Fixed

Comment by Ruslan [ 29/Dec/12 ]

Can you help me. I'm having same problem. But your link doesn't work.

Comment by Miloslav "adrive" Kmet [ 29/Dec/12 ]

You must have very old source code. The bug was fixed 2 years ago. Just compare your OCI8 driver with https://github.com/doctrine/dbal/tree/master/lib/Doctrine/DBAL/Driver/OCI8





[DBAL-54] Incorrect sequence dropping in PostgreSQL Created: 21/Sep/10  Updated: 09/Oct/12  Resolved: 23/Sep/10

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: 2.2.2
Fix Version/s: 2.0.0-RC1-RC3

Type: Bug Priority: Critical
Reporter: Tomasz Jędrzejewski Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None
Environment:

postgresql 8.4.3, Arch Linux 64-bit



 Description   

Currently, DBAL drops the PostgreSQL sequences using the query:

DROP SEQUENCE sequencename

While it is quite correct at the first look, it fails, if the sequence is actually used by a table. Because Doctrine 2 ORM tries to drop the sequences before the tables, it makes impossible to drop a database schema in PostgreSQL due to the following exception:


$ php53 doctrine.php orm:schema-tool:drop
Dropping database schema...
PDOException
SQLSTATE[2BP01]: Dependent objects still exist: 7 ERROR: cannot drop sequence admins_id_seq because other objects depend on it
DETAIL: default for table admins column id depends on sequence admins_id_seq
HINT: Use DROP ... CASCADE to drop the dependent objects too.
/.../Libs/Doctrine/DBAL/Connection.php
Line 570
Trace:
0. PDO::query on line 570
1. Doctrine\DBAL\Connection::executeQuery on line 484
2. Doctrine\ORM\Tools\SchemaTool::dropSchema on line 78
3. Doctrine\ORM\Tools\Console\Command\SchemaTool\DropCommand::executeSchemaCommand on line 59
4. Doctrine\ORM\Tools\Console\Command\SchemaTool\AbstractCommand::execute on line 159
5. Symfony\Component\Console\Command\Command::run on line 205
6. Symfony\Component\Console\Application::doRun on line 117
7. Symfony\Component\Console\Application::run on line 7


A solution is simply to add the "CASCADE" keyword at the end of the query.

Although I encountered this problem on DBAL 2.0-beta4, I checked the most up-to-date code on Git, and the problem is still present there.



 Comments   
Comment by Benjamin Eberlei [ 21/Sep/10 ]

Would it help to drop sequences after tables? If then i would just move the code blocks.

Comment by Tomasz Jędrzejewski [ 21/Sep/10 ]

In this particular case - yes, it would help. But consider that different database engines may have different dependencies between schema elements and be more or less restrictive, so they may require different order of code blocks. I'd recommend to make a bit deeper investigation here in order not to cause potential problems with other database engines.

Comment by Benjamin Eberlei [ 23/Sep/10 ]

Fixed

Comment by Jon Wadsworth [ 20/Jun/12 ]

This issue is happening again with Doctrine 2.2.2 on Postgres 9.1.3. when trying to drio a database I get this message even with --full-database

> php doctrine.php orm:schema-tool:drop --force --full-database
Dropping database schema...

[PDOException]
SQLSTATE[2BP01]: Dependent objects still exist: 7 ERROR: cannot drop sequence policycategory_id_seq because other objects depend on it
DETAIL: default for table policycategory column id depends on sequence policycategory_id_seq
HINT: Use DROP ... CASCADE to drop the dependent objects too.

I would love to help diagnose, just let me know what you need and I will be more than happy to help.

Comment by Jon Wadsworth [ 09/Oct/12 ]

I forgot to update this for anyone else who might have had my problem. The issue was solved for me when I was reviewing some models. The project was originally intended for MySQL and Generated Value Strategy was not set to Auto. Upon changing it to auto, everything worked correctly.





[DBAL-51] "No identifier/primary key specified for Entity" problem, Doctrine Beta 3 cannot find primary key Created: 31/Aug/10  Updated: 27/Nov/10  Resolved: 27/Nov/10

Status: Resolved
Project: Doctrine DBAL
Component/s: Schema Managers
Affects Version/s: 2.0.0-BETA4
Fix Version/s: 2.0.0-RC1-RC3

Type: Bug Priority: Major
Reporter: Minxuan GUO Assignee: Juozas Kaziukenas
Resolution: Fixed Votes: 0
Labels: None
Environment:

windows xp, sql server 2008, php 5.3



 Description   

when execute

php doctrine.php orm:convert-mapping --from-database annotation "Entities"

get error message

No identifier/primary key specified for Entity 'Classname(Tablename)'. Every Entity must have an identifier/primary key.

For resolving this problem
I've replaced the line

public function loadMetadataForClass($className, ClassMetadataInfo $metadata)
{
...
$indexes = $this->tables[$tableName]->getIndexes();
...
}

in function "loadMetadataForClass" in \\Doctrine\ORM\Mapping\Driver\DatabaseDriver.php by

public function loadMetadataForClass($className, ClassMetadataInfo $metadata)
{
...
$indexes = $this->_sm->listTableIndexes($tableName);
...
}

then the beta 3 works for my date base

It is because doctrine look for $indexes['prime'] to construit the primary key in entities. when we use "$this->tables[$tableName]>getIndexes()", the keys in $indexes are the real name of indexes of the data base, and in my database, the primary key indexes are named PK_TABLENAME. So I have to use $this>_sm->listTableIndexes($tableName) to pre-edit the indexes before get the list



 Comments   
Comment by Benjamin Eberlei [ 15/Sep/10 ]

This is an error in the MSSQL SchemaManager, it is not correctly setting the primary = true key in the index retrieve method. I move that issue to DBAL and reassign to juokaz

Comment by Juozas Kaziukenas [ 14/Nov/10 ]

I believe this is now fixed, but I'll test more https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Schema/MsSqlSchemaManager.php#L118

Comment by Benjamin Eberlei [ 27/Nov/10 ]

Fixed.





[DBAL-43] Doctrine\DBAL\Platforms\MsSqlPlatform Generates invalid T-SQL Created: 15/Aug/10  Updated: 27/Nov/10  Resolved: 27/Nov/10

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: 2.0.0-BETA3
Fix Version/s: 2.0.0-RC1-RC3

Type: Bug Priority: Major
Reporter: Karl Southern Assignee: Juozas Kaziukenas
Resolution: Fixed Votes: 0
Labels: None
Environment:

Any version of SQLSrv that I have available (2000-2008 R2)



 Description   

MsSqlPlatform::getAlterTableSQL generates a reasonable quantity of invalid T-SQL (to my knowledge, I'd happily be corrected if wrong).

Unfortunately SqlSrv (to my knowledge) only accepts "ALTER old_old_name column_definition" and renames of tables and columns are only capable using a stored procedure.

I'm happy to produce a patch but I think I need a bit of guidance to do so more quickly

The major one is that getAlterTableSQL will need to produce multiple SQL statements, but in my testing I'm not able to get this to do so without some additional problems, and I've not yet had the opportunity to dive into the bowels of the rest of the schema bits and bobs to understand why. If anyone could point me in the vague direction that would be really handy



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

Isn't this fixed in current master https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Platforms/MsSqlPlatform.php#L226 ?

Comment by Benjamin Eberlei [ 27/Nov/10 ]

Fixed





[DBAL-61] Incompatible transactions in OCI8 driver with other drivers (pdo_oci, pdo_mysql, pdo_pgsql) Created: 09/Nov/10  Updated: 11/Nov/10  Resolved: 11/Nov/10

Status: Resolved
Project: Doctrine DBAL
Component/s: Drivers
Affects Version/s: 2.0.0-BETA4
Fix Version/s: 2.0.0-RC1-RC3

Type: Bug Priority: Major
Reporter: Miloslav "adrive" Kmet Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None
Environment:

PHP Version 5.3.3-1ubuntu9, OCI8 1.4.1, Oracle 10.2.0.4.0



 Description   

When I try to insert some data, it is not saved into database.

$connectionOptions['oci8'] = array(
    'driver' => 'oci8',
    'dbname' => 'BOOK',
    'user' => 'doctrine',
    'password' => 'doctrine',
//    'charset' => 'AL32UTF8',
);

$em = EntityManager::create($connectionOptions['oci8'], $config, $evm);
$conn = $em->getConnection();
$conn->connect();
$conn->insert('my_table', array('my_column' => 'Some value'));

When I invoke the previous code on any other DBAL driver, like pdo_oci, pdo_mysql, pdo_pgsql, the row is inserted.

That's because Oracle is transactional, and everything need to be commited. This behavior prevent's me (and I think in a feature not only me), to use 3rd party code (bundles, models, plugins...) in my applications running oracle. This behavior prevents developers to write portable code with DBAL. The solution is to make OCI8Driver commit everything after invoking oci_execute(), the same way how Doctrine_Adapter_Oracle works in Doctrine1. (https://github.com/doctrine/doctrine1/blob/master/lib/Doctrine/Adapter/Oracle.php)



 Comments   
Comment by Benjamin Eberlei [ 09/Nov/10 ]

Scheduled for RC1, thanks for the patch - I will apply asap.

Comment by Benjamin Eberlei [ 11/Nov/10 ]

Fixed





[DBAL-41] missing column type "float" Created: 27/Oct/09  Updated: 31/Oct/10  Resolved: 31/Oct/10

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0.0-RC1-RC3

Type: New Feature Priority: Major
Reporter: Christian Ehmig Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 1
Labels: None

Sub-Tasks:
Key
Summary
Type
Status
Assignee
DBAL-70 MySql Platform is missing FloatType m... Sub-task Resolved Benjamin Eberlei  

 Description   

The former supported column type "float" is not defined in Doctrine\DBAL\Types\Type.

I noticed that floats are mapped like numerics/decimals within mysq right nowl:

protected function _getPortableTableColumnDefinition($tableColumn)
    {
       ...
        // Map db type to Doctrine mapping type
        switch ($dbType) {
            ...
            case 'float':
            case 'double':
            case 'real':
            case 'numeric':
                $type = 'decimal';
                break;

I suggest to map them to a "true" float and double as available in mysql, since they use less storage space compared to numerics with fixed decimals in certain cirtumstances (-> performance issue). http://dev.mysql.com/doc/refman/5.0/en/storage-requirements.html



 Comments   
Comment by Guilherme Blanco [ 03/Dec/09 ]

This issue was already fixed before. Check out line 192 in MySqlSchemaManager.php

Comment by Benjamin Eberlei [ 18/Jul/10 ]

This issue is regarding the support for an additional Type "Float" vs the "Decimal" which is a precise type.

A quick google over all the vendors shows that they all support floating point numbers.

Comment by Steffen Vogel [ 20/Oct/10 ]

Push...
Tut sich hier noch was? Oder soll ich mir den Typ lieber selbst implementieren? Bringt es was wenn ich ihn euch dann per Pull-Request ins github mergen kann?

gruß Steffen

Comment by Benjamin Eberlei [ 31/Oct/10 ]

All currently supported databases have a "DOUBLE PRECISION" type or use that as an alias for their float. Supporting this will be super-easy

Comment by Benjamin Eberlei [ 31/Oct/10 ]

Implemented and to be released with the RC1





[DBAL-16] dbal:import throws LogicException - Cannot add an argument after an array argument. Created: 02/Jun/10  Updated: 30/Oct/10  Resolved: 30/Oct/10

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: 2.0.0-BETA2
Fix Version/s: 2.0.0-RC1-RC3

Type: Bug Priority: Trivial
Reporter: Glen Ainscow Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 1
Labels: None

Issue Links:
Duplicate
is duplicated by DDC-791 CLI dbal:import exception Resolved

 Description   

If I run the following command:

php doctrine.php dbal:import "..\data\sql\initial-data.sql"

I get:

[LogicException]
Cannot add an argument after an array argument.


 Comments   
Comment by Benjamin Eberlei [ 04/Jun/10 ]

This seems to be a bug in the symfony console component, i'll check it out.

Comment by Benjamin Eberlei [ 28/Jun/10 ]

pushed bug upstream, marking as trivial

Comment by Nurul Ferdous [ 26/Aug/10 ]

I am getting same. it seems an old issue. we would to see it resolved.

Comment by Benjamin Eberlei [ 26/Aug/10 ]

As i said, its an upstream bug. Symfony hasnt fixed it yet.

Comment by Aaron Heimlich [ 07/Oct/10 ]

The Symfony bug that this relates to (http://trac.symfony-project.org/ticket/8336) has been fixed for a while now (see http://github.com/symfony/symfony/blob/master/src/Symfony/Component/Console/Input/InputDefinition.php#L71).

Comment by Benjamin Eberlei [ 30/Oct/10 ]

Updated to latest Console version to fix this bug.





[DBAL-55] Nested transaction emulation doesn't support rollback inside a nested transaction Created: 29/Sep/10  Updated: 01/Oct/10  Resolved: 01/Oct/10

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: 2.0.0-BETA4
Fix Version/s: 2.0.0-RC1-RC3

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


 Description   

It seems like beginTransaction() counts transaction nesting levels, but it doesnt set a savepoint when starting a new nesting level, nor does it therefore support rollbacks when rolling back inside a nested transaction. This means that I could call rollback() and it doesnt actually do anything, which imho is a bug.

The feature of using savepoints to emulate nested transactions properly seems to be present in Doctrine1.



 Comments   
Comment by Lukas Kahwe [ 30/Sep/10 ]

ok .. i am working on a patch

Comment by Benjamin Eberlei [ 30/Sep/10 ]

I guess we need new methods on AbstractPlatform to return the SQL to set, release and rollback a savepoint and then extend the Doctrine\DBAL\Connection to work with that.

Comment by Lukas Kahwe [ 30/Sep/10 ]

yup .. thats what i am doing

Comment by Lukas Kahwe [ 30/Sep/10 ]

did some initial work: http://github.com/lsmith77/dbal/tree/savepoints

not quite sure about the changes i had to do in the unittest.
probably should add new unit tests too.
also there are a couple of questions i have in the connection class

Comment by Benjamin Eberlei [ 01/Oct/10 ]

merged.





[DBAL-49] PDOSqlsrv's constructor breaks when using non "local" server host Created: 07/Sep/10  Updated: 23/Sep/10  Resolved: 23/Sep/10

Status: Resolved
Project: Doctrine DBAL
Component/s: Drivers
Affects Version/s: 2.0.0-BETA4
Fix Version/s: 2.0.0-RC1-RC3

Type: Bug Priority: Major
Reporter: Aaron DM Assignee: Juozas Kaziukenas
Resolution: Fixed Votes: 0
Labels: None
Environment:

Windows 7, Apache 2.1, PHP 5.3.3, Microsoft SQL Server 2008 Enterprise Edition



 Description   

Problem:

Currently, the _constructPdoDsn() for the PDOSqlsrv driver works fine only if the host provided is: local or localhost.
If using an IP address, this breaks. Reason is because _constructPdoDsn() applies ( and ) around the host.

        $dsn = 'sqlsrv:server=(';
        if (isset($params['host'])) {
            $dsn .= $params['host'];
        }
        $dsn .= ')';

This is fine for when $params['host'] = 'local'; because I believe local is a name pipe (I think) and to properly use it you need to add the brackets around it

However if $params['host'] = '127.0.0.1'; this breaks!

Fix:

Get rid of the forced brackets

        $dsn = 'sqlsrv:server=';
        if (isset($params['host'])) {
            $dsn .= $params['host'];
        }

That way, when supplying local as a host, you have to enter (local) (which makes more sense as that's how you would do it normally in other applications).



 Comments   
Comment by Benjamin Eberlei [ 23/Sep/10 ]

This is fixed in master.





[DBAL-50] PgSQL driver does not create indexes on foreign key columns Created: 18/Aug/10  Updated: 11/Sep/10  Resolved: 11/Sep/10

Status: Resolved
Project: Doctrine DBAL
Component/s: Schema Managers
Affects Version/s: 2.0.0-BETA4
Fix Version/s: 2.0.0-RC1-RC3

Type: Bug Priority: Critical
Reporter: Petr Motejlek Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

The PostgreSQL database does not create indexes for foreign key columns, the user has to create them by hand. I think that indexes for foreign keys should be created automatically... On my system, an index will not be created automatically for the group_id column in the user table.

/**
 * @Entity
 */
class User {
    /**
     * @ManyToOne(targetEntity="Group", inversedBy="users")
     */
    protected $group;
}

/**
 * @Entity
 */
class Group {
    /**
     * @OneToMany(targetEntity="User", mappedBy="group")
     */
    protected $users;

    public function __construct() {
        $this->users = new \Doctrine\Common\Collections\ArrayCollection();
    }
}

I am using current git clone and PgSQL 8.4.



 Comments   
Comment by Petr Motejlek [ 09/Sep/10 ]

I'd just like to add that there's an even worse problem with this – the indices are not created even for tables that Doctrine creates automatically – for example the joining tables...

Comment by Benjamin Eberlei [ 09/Sep/10 ]

i'll look into it.

Comment by Benjamin Eberlei [ 11/Sep/10 ]

Fixed in master, leading to several follow up bugs that all had to be fixed:

1. generate identifier allowed first char to be a number
2. postgresql composite foreign key detection left a space in the second (and more) column names
3. Index column names were not sanitized to lower-case, leading to comparison bugs.

There has been a major refactoring now such that, for each foreign key there is always an explicit index being created. On SQLite, Postgres and Oracle this can lead to quite some additional indexes being created now using SchemaTool --update. MySQL already did this implicitly.

There are now heuristics that detect duplicate indexes (based on columns indexed) and override rules (adding primary on columns foo, bar will delete index on columns foo bar).

Comment by Benjamin Eberlei [ 11/Sep/10 ]

Note, this commit will not get into Doctrine ORM master unless you update the git-submodule explicitly:

cd lib/vendor/doctrine-dbal
git checkout master

For RC-1 this will be visible to the ORM trunk/master also.





[DBAL-46] Fix doctrine-dbal console command Created: 01/Sep/10  Updated: 02/Sep/10  Resolved: 02/Sep/10

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: 2.0.0-BETA4
Fix Version/s: 2.0.0-RC1-RC3

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


 Description   

It still uses Symfony\Components with S.



 Comments   
Comment by Benjamin Eberlei [ 02/Sep/10 ]

fixed.





Generated at Fri Aug 01 06:04:31 UTC 2014 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.