[DBAL-860] MsSQL-Server DateTime microseconds issue Created: 11/Feb/11  Updated: 01/Apr/14  Resolved: 09/Jan/12

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

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

WindowsXP/Windows2008 R2 / PHP 5.3 / MsSQL-Server 2005 / MsSQL-PDO_PHP-Driver


Sub-Tasks:
Key
Summary
Type
Status
Assignee
DBAL-861 ensure the dateformat Y-m-d gets used... Sub-task Resolved Benjamin Eberlei  

 Description   

The string for the function getDateTimeFormatString() in the MsSqlPlatform class is 'wrong'.
The Microsoft-SQL-Server just uses 3 digits for microseconds and not 6.
So the string 'Y-m-d H:i:s.u' fails and the server states: [SQL Server]Fehler beim Konvertieren einer Zeichenfolge in einen datetime-Wert (Error when converting a string to a datetime-value) .

So this string works, but does not regard the microseconds for those how rely on them: 'Y-m-d H:i:s.000'

See also:
[...] The MS datetime column is documented to have an accuracy of only about .3 seconds anyway [...]
http://bytes.com/topic/sql-server/answers/80150-inserting-datetime-milliseconds-sql-server

http://msdn.microsoft.com/en-gb/library/ms186819.aspx (Section: Remarks)



 Comments   
Comment by Benjamin Eberlei [ 11/Feb/11 ]

Assigned to juozas, but i think the issue here is that you have to use Datetime2, or add your own type replacing the shipped one to support the old datetime.

Comment by Martin Weise [ 14/Feb/11 ]

Ok, I had another problem with the datetime, but this does not regard the problem of this issue ( at least not totally).
The problem with the MsSQL-Server before 2008 is that there is no data type named 'datetime2', just 'datetime'.
The next problem is that every date conversion for a query is done in the language set upon conection time.
Thus leads to a problem, when it is not possible to set the connection language.

So the problem is that the MsSQL-Server relies on the settings above.
In my case the datetime conversion failed, as the server always thought that the datetime-string would come in
the following format: Y-d-m . This is not true, as the default format string is: Y-m-d . So every insert/update query fails.
To solve the problem I did that: $entityManager->getConnection()->exec('SET DATEFORMAT ymd'); .
This way I ensured that the dateformat string works fine, except the issue problem.

To solve the problem in general, it would be helpful to subclass the MsSqlPlatform into a class named MsSql2005Platform or something like this and just override the getDateTimeFormatString and upon connection setting the format for the queries
as mentioned before.

Hope this helps out.
Besides, here a link to the datetime problem (in german): http://www.insidesql.org/blogs/frankkalis/2010/08/19/der-ultimative-guide-fuer-die-datetime-datentypen

Comment by Juozas Kaziukenas [ 14/Feb/11 ]

I have somehow manage to miss the fact that datetime2 wasn't around in datetime... What I'm thinking now is there a need for datetime2 in Doctrine at all. If only thing it brings is additional accuracy for microseconds, maybe best idea would be to use datetime for 2008 installs too if used from Doctrine. However datetime is now a standard and Microsoft recommends to use it for new installs. What I can do is I can always insert 3 fractional points to datetime column as both datetime2 and datetime would accept it as valid date string.

We can have separate platforms for 2008 and 2005 servers, but that would be quite resource intensive. Let me see what is the best way to fix it.

Regards to Dateformat, I guess the solution would be to set format on connection, how you suggested. How about you create a separate ticket for this and assign it to me.

Comment by Benjamin Eberlei [ 14/Feb/11 ]

Oracle also has an Session Init Listener that handles the date format things, i guess we can take this as example. However I think having Mssql2005Platform sounds goods also, it would be only one method to override.

Comment by Martin Weise [ 09/Aug/11 ]

To solve this issue, at least for MsSQL-Server datetime data types, change the following TypeClass of Doctrine by adding
this check before converting to PHP\DateTime in 'convertToPHPValue()' :

if( strlen($value) == 24 && $platform->getDateTimeFormatString() == 'Y-m-d H:i:s.u')
$value = $value.'000';

I know this is propably very specific, but I do not know, how other DBs handle microseconds in datetime strings.

Comment by Martin Weise [ 08/Sep/11 ]

I fixed this bug with some changes in the DateTimeType class. As there is no Explicit MSSQL2005 Plattform this change would also affect datetime2 type in the SQLServer 2008 plattform, which is the data type that has 6 microseconds.
So either populate a MSSQLServer2005 Plattform, or introduce a new DateTimeType for the 2005 platform.

DateTimeType.php

<?php
/*
 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
 * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
 * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
 * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
 * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
 * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
 * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
 * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
 * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
 * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
 * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 *
 * This software consists of voluntary contributions made by many individuals
 * and is licensed under the LGPL. For more information, see
 * <http://www.doctrine-project.org>.
 */

namespace Doctrine\DBAL\Types;

use Doctrine\DBAL\Platforms\AbstractPlatform;

/**
 * Type that maps an SQL DATETIME/TIMESTAMP to a PHP DateTime object.
 *
 * @since 2.0
 */
class DateTimeType extends Type
{
    public function getName()
    {
        return Type::DATETIME;
    }

    public function getSQLDeclaration(array $fieldDeclaration, AbstractPlatform $platform)
    {
        return $platform->getDateTimeTypeDeclarationSQL($fieldDeclaration);
    }

    public function convertToDatabaseValue($value, AbstractPlatform $platform)
    {
		if( $value === null)
			return null;

		$value = $value->format($platform->getDateTimeFormatString());

		if( strlen($value) == 26 &&
			$platform->getDateTimeFormatString() == 'Y-m-d H:i:s.u' &&
			$platform instanceof \Doctrine\DBAL\Platforms\MsSqlPlatform )
			$value = substr($value, 0, \strlen($value)-3);

		return $value;

    }

    public function convertToPHPValue($value, AbstractPlatform $platform)
    {
        if ($value === null) {
            return null;
        }

		if( strlen($value) == 24 && $platform->getDateTimeFormatString() == 'Y-m-d H:i:s.u')
			$value = $value.'000';

        $val = \DateTime::createFromFormat($platform->getDateTimeFormatString(),$value);
        if (!$val) {
            throw ConversionException::conversionFailedFormat($value, $this->getName(), $platform->getDateTimeFormatString());
        }
        return $val;
    }
}

Comment by Benjamin Eberlei [ 09/Jan/12 ]

Added SQLServer2005 platform that uses DATETIME and the .000 format as per instructions of Martin.





[DBAL-322] Change Detection fails when 'unsigned' is used in MySQL Schema Created: 14/Aug/12  Updated: 14/Aug/12  Resolved: 14/Aug/12

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

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


 Comments   
Comment by Marcus Stöhr [ 14/Aug/12 ]

This has been already fixed in https://github.com/doctrine/dbal/commit/e44a6c36a8d9e0aa8d8abb2c91c443ced5a6e39e.





[DBAL-215] DoctrineBundle Configuration File Created: 03/Feb/12  Updated: 21/Nov/13  Resolved: 21/Nov/13

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

Type: Improvement Priority: Major
Reporter: Aaron Scherer Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

In the DoctrineBundle, there is no support for "master" or "slave", yet the "MasterSlaveConnection" in the new DBAL branch wants both of them in the connection.



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

Fixed in PR:
https://github.com/doctrine/DoctrineBundle/pull/53

See Documentation:
http://symfony.com/doc/current/reference/configuration/doctrine.html





[DBAL-212] Unknown database type longvarchar requested, Doctrine\DBAL\Platforms\SqlitePlatform may not support it. Created: 28/Jan/12  Updated: 28/Jan/12  Resolved: 28/Jan/12

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

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


 Description   

SqlitePlatform lacks "longvarchar" type mapping which is extensively used by browsers sqlite databases (e.g. places in FF, history in Chrome).
Trying to get a schema ends up with 'Unknown database type longvarchar requested, Doctrine\DBAL\Platforms\SqlitePlatform may not support it.' message.



 Comments   
Comment by Benjamin Eberlei [ 28/Jan/12 ]

Fixed





[DBAL-211] wrong where clause in PostgreSqlPlatform::getTableWhereClause Created: 26/Jan/12  Updated: 28/Jan/12  Resolved: 28/Jan/12

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

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

ubuntu + postgres



 Description   

I have the folowing table structure:

Schema "public": with one table called "users"
Schema "forums": with one table called "users"

methods like PostgreSqlPlatform::getListTableForeignKeysSQL($table, $database = '') should list FK inside $table

the default search path is "public,pg_catalog"

calling PostgreSqlPlatform::getListTableForeignKeysSQL('users') it shuld extract the FK from public.users table, but this is the current result:

[PDOException] SQLSTATE[21000]: Cardinality violation: 7 ERROR: more than one row returned by a subquery used as an expression

this exception is thrown because PostgreSqlPlatform::getTableWhereClause do not cosider the current search path.

i propose the following implementation for PostgreSqlPlatform::getTableWhereClause

 
    private function getTableWhereClause($table, $classAlias = 'c', $namespaceAlias = 'n')
    {
        $whereClause = $namespaceAlias.".nspname NOT IN ('pg_catalog', 'information_schema', 'pg_toast') AND ";
        if (strpos($table, ".") !== false) {
            list($schema, $table) = explode(".", $table);
            $whereClause .= "$classAlias.relname = '" . $table . "' AND $namespaceAlias.nspname = '" . $schema . "'";
        } else {
            // $whereClause .= "$classAlias.relname = '" . $table . "'"; // this was the current implementation
            $whereClause .= "$classAlias.relname = '" . $table . "' AND $namespaceAlias.nspname = ANY(string_to_array((select setting from pg_catalog.pg_settings where name = 'search_path'),','))";
        }

        return $whereClause;
    }

this implementation will restrict the search range only to current "search_path".

(sorry for my english)



 Comments   
Comment by Benjamin Eberlei [ 28/Jan/12 ]

This looks very good.

Comment by Benjamin Eberlei [ 28/Jan/12 ]

Fixed





[DBAL-207] RemoveNamespacedAssets: Foreign Key removing does not work correctly Created: 22/Jan/12  Updated: 22/Jan/12  Resolved: 22/Jan/12

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: 2.2-RC1/RC2
Fix Version/s: 2.2.0-RC3, 2.2
Security Level: All

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


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

Fixed.





[DBAL-206] OraclePlatform causes problems with more schemas with same table names Created: 20/Jan/12  Updated: 21/Jan/12  Resolved: 21/Jan/12

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: 2.1.5
Fix Version/s: 2.1.6, 2.2
Security Level: All

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

Oracle database



 Description   

OraclePlatform is using the ALL_* tables to fetch schema information but is only supplying the table name in the where condition. This causes problems when you have multiple schemas with tables that have the same name. Their columns/FK get mixed up.

My colleague and I have traced the problem down to the OraclePlatform class and replaced the ALL_* tables with USER_*. The fix for that is on github https://github.com/FranPregernik/dbal/commit/c70bc462b49a168105304cdff0086dcd15cc347d.

As mentioned in the comment message the other fix would be to fetch the schema name (user) of the table and add it to the where part of the queries. Something like this:

t.owner = user

A pull request has been made on github for this.



 Comments   
Comment by Benjamin Eberlei [ 21/Jan/12 ]

Fixed.





[DBAL-205] MySQL SchemaManager doesn't handle composite foreign keys properly Created: 19/Jan/12  Updated: 21/Jan/12  Resolved: 21/Jan/12

Status: Resolved
Project: Doctrine DBAL
Component/s: Schema Managers
Affects Version/s: 2.1.5
Fix Version/s: 2.1.6, 2.2
Security Level: All

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


 Description   

The MySQL SchemaManager can not properly generate a Schema from the database if a table has a foreign key that spans multiple columns.
Therefore the comparator tries to drop the one index as individual indexes.

That leads to an error if the resulting SQL is executed because these indexes do not exist (i.e. via app/console doctrine:schema:update --force)

symfony2#app/console doctrine:schema:update --dump-sql
...
ALTER TABLE table1 DROP FOREIGN KEY FK_C1B1712387FE737264DE5A5511B8B3E;
DROP INDEX IDX_C1B1712387FE7372 ON table1;
DROP INDEX IDX_C1B1712364DE5A5 ON table1;
DROP INDEX IDX_C1B17123511B8B3E ON table1;
ALTER TABLE table1 ADD CONSTRAINT FK_C1B1712387FE737264DE5A5511B8B3E FOREIGN KEY (column1, column2, column3) REFERENCES table2(column1, column2, column3);
...





[DBAL-204] Handling of explicit Schemas is wrong in comparator Created: 18/Jan/12  Updated: 21/Jan/12  Resolved: 21/Jan/12

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

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


 Description   

if you are on db "foo" and compare table "bar" to "foo.bar". it shouldnt drop one and create the other one. They are the same!



 Comments   
Comment by Benjamin Eberlei [ 21/Jan/12 ]

Fixed.

This includes facilities to filter schema assets when creating from a SchemaManager:

$connection->getConfiguration()->setFilterSchemaAssetsExpression("foo\.bar");

Additionally in the ORM now when using a database vendor that does not support schemas the "namespaced" assets are removed.

Say you are connected to database "foo" and you have an entity defined as @Table("bar.baz"), then all SQL generated for that entity will be removed.





[DBAL-203] Fix SQLServer version mess (2003, 2005, 2008) Created: 15/Jan/12  Updated: 15/Jan/12  Resolved: 15/Jan/12

Status: Resolved
Project: Doctrine DBAL
Component/s: Drivers, Platforms
Affects Version/s: 2.1.5, 2.2-BETA2
Fix Version/s: 2.2
Security Level: All

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


 Description   

The current SqlSrv platform implicitly depends on SQL Server 2008. A differentation between the common versions 2003, 2005 and 2008 is necessary.



 Comments   
Comment by Benjamin Eberlei [ 15/Jan/12 ]

implemented





[DBAL-201] Remote IBM DB2 connection needs protocol specified Created: 13/Jan/12  Updated: 21/Jan/12  Resolved: 21/Jan/12

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

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

using doctrine2 included in symfony2 2.0.9, running on MAMP on OSX



 Description   

Thanks so much for adding DB2 support to Doctrine2, it's awesome!

I'm using it to connect to a remote DB2 database, and in db2driver.php, it is expecting the 'protocol' parameter to be set. I tried the obvious, adding a database_protocol to my parameters.ini file (to match the other database things in there), but that didn't work.

I did a temporary fix of hardcoding it in the db2driver.php to be PROTOCOL=TCPIP , and it works.

So i think the proper fix would be to add the code so that database_protocol in parameters.ini is picked up.



 Comments   
Comment by Benjamin Eberlei [ 21/Jan/12 ]

This is primarily a DoctrineBundle bug. However i fixed it in DBAL to default to TCPIP protocol parameter now.

DB2 is not "really" supported. I have considerable problems with it segfaulting the DBAL testsuite. You should be very careful.





[DBAL-197] Cannot drop database schema with blob type Created: 05/Jan/12  Updated: 09/Jan/12  Resolved: 09/Jan/12

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: 2.2-BETA1, 2.2-BETA2
Fix Version/s: 2.2
Security Level: All

Type: Bug Priority: Major
Reporter: Sascha-Oliver Prolic Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None
Environment:

MySQL 5.1.58, for debian-linux-gnu (x86_64)



 Description   

I have an entity with a blob type. When I create the database schema via cli, everthing is okay.
When i try to drop the schema, I receive the following error:
[Doctrine\DBAL\DBALException]
Unknown database type longblob requested, Doctrine\DBAL\Platforms\MySqlPlatform may not support it.






[DBAL-196] The function fetchAll(PDO::FETCH_ALL, 'MyClass') doesn't create object of MyClass Created: 06/Jan/12  Updated: 21/Jan/12  Resolved: 21/Jan/12

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

Type: Bug Priority: Major
Reporter: Antoine Froger Assignee: Fabio B. Silva
Resolution: Fixed Votes: 0
Labels: None


 Description   

The code below doesn't create objects of MyClass when it has to.
Instead it create StdClass objects

$stmt = $db->prepare($sql);
$stmt->execute();

$results = $stmt->fetchAll(
    \PDO::FETCH_CLASS,
    'MyClass'
);

The problem comes from the file Doctrine/DBAL/Statement.php

    /**
     * Returns an array containing all of the result set rows.
     * 
     * @param integer $fetchStyle
     * @param integer $columnIndex
     * @return array An array containing all of the remaining rows in the result set.
     */
    public function fetchAll($fetchStyle = PDO::FETCH_BOTH, $columnIndex = 0)
    {
	if ($columnIndex != 0) {
            return $this->_stmt->fetchAll($fetchStyle, $columnIndex);
        }
        return $this->_stmt->fetchAll($fetchStyle);
    }

The line

if ($columnIndex != 0) {

must be replace by

if ($columnIndex !== 0) {

because the parameter $columnIndex is not always an integer and could be a name of a class : see the example n°4 in php doc http://www.php.net/manual/en/pdostatement.fetchall.php



 Comments   
Comment by Benjamin Eberlei [ 21/Jan/12 ]

Fixed and merged into 2.2





[DBAL-195] Method AbstractSchemaManager->dropAndCreateSequence() contains erroneous code. Created: 06/Jan/12  Updated: 09/Jan/12  Resolved: 09/Jan/12

Status: Resolved
Project: Doctrine DBAL
Component/s: Schema Managers
Affects Version/s: 2.1.5
Fix Version/s: 2.1.6, 2.2
Security Level: All

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

Attachments: Text File AbstractSchemaManager_dropAndCreateSequence.patch    

 Description   

I needed to use the function and looking at the code I found that it seemed partially implemented, cut and pasted from something else or just not ported from an earlier implementation. I'm now submitting a patch that fixes this issue. I didn't modify the AbstractSchemaManager->dropSequence($name) signature to become AbstractSchemaManager->dropSequence($sequence) but it might be a good idea to refactor it (guess that would be another issue though )



 Comments   
Comment by Benjamin Eberlei [ 09/Jan/12 ]

Oh the code worked before, but was refactored. This method was forgotten.

Comment by Benjamin Eberlei [ 09/Jan/12 ]

Fixed.





[DBAL-194] BlobType should implement getBindingType() Created: 01/Jan/12  Updated: 03/Jan/12  Resolved: 02/Jan/12

Status: Resolved
Project: Doctrine DBAL
Component/s: Schema Managers
Affects Version/s: 2.2-BETA1
Fix Version/s: 2.2-BETA2, 2.2

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

PHP 5.3.8
PostgreSQL 9.1


Attachments: Text File fix.patch    

 Description   

BlobType should implement getBindingType() and return PDO::PARAM_LOB

Currently (2.2-BETA1) DBAL uses PDO::PARAM_STR and thus stores the data incorrectly.

Working patch is attached.



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

Fixed





[DBAL-192] GH-86: Remove a type object if a type is overrided Created: 26/Dec/11  Updated: 03/Jan/12  Resolved: 28/Dec/11

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

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


 Description   

Pull-Request was automatically synchronized: https://github.com/doctrine/dbal/pull/86






[DBAL-190] Column type comment SQL is missing during table creation Created: 23/Dec/11  Updated: 03/Jan/12  Resolved: 28/Dec/11

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: None
Fix Version/s: 2.1.6, 2.2-BETA2, 2.2
Security Level: All

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

Latest DBAL master



 Description   

Column type comment is generated properly only with MySQL, and is not generated on platforms that support comment on column statements (Oracle, PgSQL).



 Comments   
Comment by Benjamin Eberlei [ 23/Dec/11 ]

This issue is referenced in Github Pull-Request GH-84
https://github.com/doctrine/dbal/pull/84

Comment by Benjamin Eberlei [ 28/Dec/11 ]

Related Pull Request was closed: https://github.com/doctrine/dbal/pull/84

Comment by Benjamin Eberlei [ 28/Dec/11 ]

Fixed





[DBAL-188] Make doctrine and sqlite friends Created: 18/Dec/11  Updated: 18/Dec/11  Resolved: 18/Dec/11

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

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


 Description   

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

Schema processing for SQLite is broken in a number of common situations. These patches fix handling of the following:

String column defaults: For columns with a default value that is a string, SQLite returns them wrapped in single quotes. Doctrine does not strip these, so it would treat a value "foobar" as "'foobar'" (with single quotes as part of the value).
Auto-increment: SQLite handling of auto-increment is unusual. In particular, it supports it only on an integer column which is the sole primary key for a table. In addition, it will automatically increment values of an integer primary key column regardless of whether it has been defined as autoincrement BUT, unlike autoincrement, these values are not guaranteed to be unique.
Most problematically, there is no way (without parsing the "create" statements stored in sqlite_master) to determine whether a column is marked as auto-incrementing. Doctrine was treating SQLite integer primary keys as auto-incrementing, but this is not correct and does not work for composite primary keys.
Composite primary keys: As a side-effect of Doctrine treating integer primary keys in SQLite as auto-incrementing and of how SQLite requires autoincrement and primary keys to be declared, it would generate invalid create statements for composite keys in SQLite.
Special indexes: SQLite sometimes automatically generates indexes, which Doctrine treated the same as any other. Because they are internal, however, their names are reserved, so they could not be used to recreate the same index and, since they are automatic, they aren't actually a part of the defined schema.

I've added to the tests to catch these situations in the future as well.






[DBAL-187] GH-83: Added a LoggerChain Created: 15/Dec/11  Updated: 15/Dec/11  Resolved: 15/Dec/11

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

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


 Description   

Pull-Request was automatically synchronized: https://github.com/doctrine/dbal/pull/83

This logger allows registering several loggers in the connection



 Comments   
Comment by Benjamin Eberlei [ 15/Dec/11 ]

Merged





[DBAL-186] GH-82: Schema events Created: 13/Dec/11  Updated: 19/Dec/11  Resolved: 19/Dec/11

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

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


 Description   

Pull-Request was automatically synchronized: https://github.com/doctrine/dbal/pull/82

Trigger schema related events to allow custom create/drop/update queries.



 Comments   
Comment by Benjamin Eberlei [ 19/Dec/11 ]

Merged





[DBAL-177] Have Schema Assets handle "foo.bar" syntax correctly. Created: 31/Oct/11  Updated: 16/Nov/11  Resolved: 16/Nov/11

Status: Resolved
Project: Doctrine DBAL
Component/s: Schema Managers
Affects Version/s: 2.1.3
Fix Version/s: 2.2
Security Level: All

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





[DBAL-176] DBAL logging doesnt work correctly with Prepared Statements Created: 29/Oct/11  Updated: 30/Oct/11  Resolved: 30/Oct/11

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

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





[DBAL-170] Add mysqli driver Created: 25/Sep/11  Updated: 21/Nov/11  Resolved: 21/Nov/11

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

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


 Description   

Add a mysqli driver



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

Implemented





[DBAL-169] PostgreSQL Session init Created: 24/Sep/11  Updated: 24/Sep/11  Resolved: 24/Sep/11

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

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


 Description   

During PostgreSQL Session init it may be interesting to set the search path to a different value than the default.



 Comments   
Comment by Benjamin Eberlei [ 24/Sep/11 ]

Implemented a generic SQLSessionInit listener that executes a single sql command after connection initializtion.

Example usage:

$evm->addEventListener(new SQLSessionInit("SET SEARCH_PATH TO foo, public, TIMEZONE TO 'Europe/Berlin'"));
$conn = DriverManager::getConnection($params, $config $evm);




[DBAL-152] Github-PR-49 by juokaz: Ignore sysdiagrams table from a list Created: 21/Aug/11  Updated: 22/Nov/11  Resolved: 22/Nov/11

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

Type: Improvement 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

{username}

:

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

Message:

Fix for the http://www.doctrine-project.org/jira/browse/DBAL-114



 Comments   
Comment by Christophe Coevoet [ 22/Nov/11 ]

This PR has been merged





[DBAL-146] Mssql platform TOP and DISTINCT ordering issue Created: 10/Aug/11  Updated: 09/Jan/12  Resolved: 09/Jan/12

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: 2.1
Fix Version/s: 2.1.6, 2.2

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

Windows 2008 R2 SqlSrv 2008 R2 IIS 7.5, fully patched


Attachments: Text File FixDisctinctTopOrderingIssue.patch    

 Description   

When doing a limit and a distinct query, DBAL generates an SQL statement in the form of SELECT TOP X DISTINCT, which SqlSrv does not like at all. Simply moving the the DISTINCT back to the start fixes this issue.

As far as I can see this is caused by the preg_replace in doModifyLimitQuery. Attached is a patch that makes it slightly more aware. There may be other phrases to check for, but none that I've come across yet.

Patch attached.



 Comments   
Comment by Benjamin Eberlei [ 09/Jan/12 ]

Fixed





[DBAL-142] Mapping Driver for Oracle does not know what to do with blobs, throws DBAL Exception for types "blob" and "long raw". Created: 02/Aug/11  Updated: 13/Mar/12  Resolved: 30/Oct/11

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: 2.1
Fix Version/s: 2.2

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

CentOS 5.0, PHP 5.3.6, Oracle 11g EE, Symfony 2.0, Doctrine 2.1


Issue Links:
Duplicate
duplicates DBAL-6 MySQL BLOB datatypes throw DoctrineEx... Resolved

 Description   

When attempting to reverse engineer an existing Oracle 11g database an exception is thrown (by DBAL) complaining that the type blob is unknown. I believe this is coming from AbstractPlatform.php. I attempted to solve the problem by add a type mapping for blob in PDOOracle\Driver.php (blob => text) and it now complains that "long raw" is unknown.

[Doctrine\DBAL\DBALException]
Unknown database type long raw requested, Doctrine\DBAL\Platforms\OraclePlatform may not support it.



 Comments   
Comment by Benjamin Eberlei [ 30/Oct/11 ]

Implemented blob support

Comment by Sergio Andres Diaz Oviedo [ 13/Mar/12 ]

Sorry. i am new in it, i am developing and app in symfony 2, and when i try to import the entities from the database i get the error:

[Doctrine\DBAL\DBALException]
Unknown database type blob requested, Doctrine\DBAL\Platform may not support it.

i am using oracle 11g, i did try (blob => 'text') in oraclepatform.php but is later send me more errors, i cant understand, i want know how can i fix it i anyway to at least can import the entities, thank you





[DBAL-141] PDO Connection Failure through TNS - PDOOracle/Driver.php line 56 Created: 01/Aug/11  Updated: 30/Oct/11  Resolved: 30/Oct/11

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: 2.1
Fix Version/s: 2.2

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

CentOS 6.0, Symfony 2.0.0 (RC), PHP 5.3.6, Oracle 11g Enterprise, Oracle InstantClient 11.0.2


Issue Links:
Duplicate
is duplicated by DBAL-136 OCI8 Driver MUST support connections ... Resolved

 Description   

On line 56 of the file ./vendor/doctrine-dbal/lib/Doctrine/DBAL/Driver/PDOOracle/Driver.php:

The line reads:
$dsn .= '))(CONNECT_DATA=(SID=' . $params['dbname'] . ')))'; should read $dsn .= '))(CONNECT_DATA=(SERVICE_NAME=' . $params['dbname'] . ')))';

If both SID and SERVICE_NAME need to be available for use, then logic should be inserted to determine which method is being used.



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

Whats the difference? the Use of SID works for me.

Comment by Daniel Lima [ 18/Aug/11 ]

Hi Benjamin,

There are some Oracle connections that are setup from SERVICE_NAME (without a SID).
In my company we always use SERVICE_NAME to setup a connection and we needed to modify the OCI connection driver from Doctrine to works fine in our environment

Take a look in: http://stackoverflow.com/questions/43866/how-sid-is-different-from-service-name-in-oracle-tnsnames-ora

Comment by Ed Anderson [ 19/Aug/11 ]

There's a subtle difference between SID and SERVICE_NAME and I think the code should somehow account for the difference. Here's why... An SID points to a physical instance at the database level (Service Identifier). If you ask for a SID you only get one shot at the connection (and hopefully the database is up). That's the legacy method of connecting to Oracle.

However, for environments that have HA installations of Oracle using RAC, the SERVICE_NAME is what is used to point to a database instance (instead of a physical Service ID). If a given database instance is down and you're using SID - meaning you're looking to connect to a specific database, the connection fails. If you're in an environment with multiple instances of the target database, then RAC figures out where to send you if you're using SERVICE_NAME and you will land on an useable instance. This is the typical way to connect when Oracle is load-balanced and in a high-availability environment.

Comment by Benjamin Eberlei [ 04/Sep/11 ]

How can we solve this issue in a BC way? I wouldn't know if I can just change it the way suggested and it will work for everyone.

Comment by Benjamin Eberlei [ 30/Oct/11 ]

Fixed by adding a new parameter 'service' which has to be true to use SERVICE_NAME instead of SID.





[DBAL-138] Connection::quote should convert non PDO types Created: 25/Jul/11  Updated: 31/Jul/11  Resolved: 31/Jul/11

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

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


 Description   

It currently doesn't so $connection->quote('foo', Type::STRING) doesn't work.



 Comments   
Comment by Alexander [ 25/Jul/11 ]

PR on github for this: https://github.com/doctrine/dbal/pull/39.

Comment by Benjamin Eberlei [ 31/Jul/11 ]

Merged PR into master





[DBAL-114] MsSqlPlatform - getListTablesSQL() get's sysdiagrams table Created: 26/Apr/11  Updated: 29/Aug/11  Resolved: 29/Aug/11

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: 2.0.4
Fix Version/s: 2.1.2, 2.2

Type: Bug Priority: Critical
Reporter: Bostjan Oblak Assignee: Juozas Kaziukenas
Resolution: Fixed Votes: 1
Labels: None
Environment:

Windows 7, PHP 5.3.5, MSSQL 2008



 Description   

getListTablesSQL() function in MsSqlPlatform.php list all tables in database.

If you have saved Database Diagrams it returns "sysdiagrams" table too.
This table have field "name" with type "sysname" which have no mapping.

If you run orm:validate-schema you get:
[Doctrine\DBAL\DBALException]
Unknown database type sysname requested, Doctrine\DBAL\Platforms\MsSqlPlatform may not support it.

Best solution is that when getting tables to ignore "sysdiagrams" tables.



 Comments   
Comment by Bostjan Oblak [ 26/Apr/11 ]

One solution is to just add "AND name != 'sysdiagrams' " to sql statement

Comment by Benjamin Eberlei [ 30/Apr/11 ]

Assigned to Jouzas

Comment by Yaroslav Zenin [ 07/Jul/11 ]

Why it is not fixed yet? The solution is so easy. Please add to repository. Because on every release I should change it manually

Comment by Benjamin Eberlei [ 29/Aug/11 ]

Fixed





[DBAL-20] Add Connection Resolver Created: 13/Jun/10  Updated: 01/Apr/12  Resolved: 19/Dec/11

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

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


 Description   

There should be an additional, optional "connectionResolver" which returns a driver instance for differentation between different drivers in Doctrine\DBAL\Connection instead of using $this->_conn (which stays the default case)

This is useful for master/slave, master/master or failover strategies inside the application



 Comments   
Comment by Diego Lewin [ 21/Jun/10 ]

I have done some working code, I extended \Doctrine\DBAL\Connection:

From the controllers/ service layer:

$em->getConnection()->setConnection('write');

try {
    $em->persist($user);
} catch (Exception $e) {
     echo $e->getMessage();
}


$em->getConnection()->setConnection('read_1');

...

$em->getConnection()->setConnection('read_2');

Obviously all the statements related with a unit of work will be associated with only one connection.

_________________________________________

When setting the event manager:

 $connectionOptions =
              array(
            'driver'    => $doctrineConfig['conn']['driv'],
            'user'      => $doctrineConfig['conn']['user'],
            'password'  => $doctrineConfig['conn']['pass'],
            'dbname'    => $doctrineConfig['conn']['dbname'],
            'host'      => $doctrineConfig['conn']['host'],
       
            'wrapperClass' =>'\Fishpond\Doctrine\DBAL\Connections\Multiple'
           
        );


        $connectionOptions['multiple_connections']['read'] = array(
        "driver" =>  "pdo_mysql",
        "user" =
        "password" =>
        "dbname"=>
        "host" =>
     

        );


        $connectionOptions['multiple_connections']['write'] = array(
        "driver" =>  "pdo_mysql",
        "user" => 
        "password" =>
        "dbname"=>
        "host" =>

        );


$em = \Doctrine\ORM\EntityManager::create($connectionOptions, $config);

_________________________________________

The new connection class itself:

namespace Fishpond\Doctrine\DBAL\Connections;


class Multiple extends \Doctrine\DBAL\Connection
{
    /**
     * An array with the different database connection used by the EntityManager.
     *
     * @var array of Doctrine\DBAL\Connection
     */
    private $_connections;

    /**
     * The index that indicate which
     * connection is used, if this index is null
     * the defaul connection is used
     *
     * @var String
     */
    private $_selectedConnection;


    /**
     * Initializes a new instance of the Connection class.
     *
     * @param array $params  The connection parameters.
     * @param Driver $driver
     * @param Configuration $config
     * @param EventManager $eventManager
     */

    public function __construct(array $params, Driver  $driver, Configuration $config = null,
       EventManager     $eventManager = null)
    {

        parent::__construct($params, $driver, $config, $eventManager);
      
        foreach ($params['multiple_connections'] as $connectionKey => $paramsMultipleConnection) {
            $this->_connections[$connectionKey] = new \Doctrine\DBAL\Connection($paramsMultipleConnection, $driver, $config, $eventManager);
        }
    }
 


    public function setConnection($selectedConnection) {
        $this->_selectedConnection = $selectedConnection;
   
        return $this;
    }


    /**
     * Establishes the connection with the database.
     *
     * @return boolean TRUE if the connection was successfully established, FALSE if
     *                 the connection is already open.
     */
    public function connect()
    {
        $status = parent::connect();
        if ($status == false) {
            return false;
        }
       
        foreach ($this->_connections as $connection) {
            $connection->connect();
        }


        return true;
    }

    /**
     * Executes an, optionally parameterized, SQL query.
     *
     * If the query is parameterized, a prepared statement is used.
     * If an SQLLogger is configured, the execution is logged.
     *
     * @param string $query The SQL query to execute.
     * @param array $params The parameters to bind to the query, if any.
     * @return Doctrine\DBAL\Driver\Statement The executed statement.
     * @internal PERF: Directly prepares a driver statement, not a wrapper.
     */
    public function executeQuery($query, array $params = array(), $types = array())
    {
    
        if ($this->_selectedConnection == null) {
            return parent::executeQuery($query, $params, $types);
        }

        return $this->_connections[$this->_selectedConnection]->executeQuery($query, $params, $types);
       
       
    }



    /**
     * Starts a transaction by suspending auto-commit mode.
     *
     * @return void
     */
    public function beginTransaction()
    {
       parent::beginTransaction();
       foreach ($this->_connections as $connection) {
            $connection->beginTransaction();
       }
    }

    /**
     * Commits the current transaction.
     *
     * @return void
     * @throws ConnectionException If the commit failed due to no active transaction or
     *                             because the transaction was marked for rollback only.
     */
    public function commit()
    {
       parent::commit();
       foreach ($this->_connections as $connection) {
            $connection->commit();
       }
    }


  /**
     * Gets the wrapped driver connection.
     *
     * @return Doctrine\DBAL\Driver\Connection
     */
    public function getWrappedConnection()
    {
        if ($this->_selectedConnection == null) {
            return parent::getWrappedConnection();
        }

        return $this->_connections[$this->_selectedConnection]->getWrappedConnection();
    }

..........
........

The class is working so far (need much more testing), but the idea is if is not selected a connection it will work as it is now. Also, an 'automatic' selection of the connection could happen in an event listener, where we could define rules about which connection should be used for different conditions/entities.

Comment by Benjamin Eberlei [ 25/Jul/10 ]

Rescheduled for Beta4

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

We could even move this post-2.0 since this is a new feature and carries the risk of opening a set of new issues.

Comment by Lars Strojny [ 02/May/11 ]

Here is what we use in production for a few weeks now:

<?php
namespace Jarlssen\Doctrine2\DBAL;

use Doctrine\DBAL\Connection,
    Doctrine\DBAL\Driver,
    Doctrine\ORM\Configuration,
    Doctrine\Common\EventManager,
    Doctrine\DBAL\Events;

class MasterSlaveConnection extends Connection
{
    /**
     * Master connection
     *
     * @var Doctrine\DBAL\Driver\Connection
     */
    protected $_masterConn;

    /**
     * Slave connection
     *
     * @var Doctrine\DBAL\Driver\Connection
     */
    protected $_slaveConn;

    public function __construct(
        array $params,
        Driver $driver,
        Configuration $config = null,
        EventManager $eventManager = null
    )
    {
        if (!isset($params['slaves']) or !isset($params['master'])) {
            throw new \InvalidArgumentsException('master or slaves configuration missing');
        }

        $params['master']['driver'] = $params['driver'];
        foreach ($params['slaves'] as &$slave) {
            $slave['driver'] = $params['driver'];
        }

        parent::__construct($params, $driver, $config, $eventManager);
    }

    public function connect($connectionName = 'slave')
    {
        $forceMasterAsSlave = false;

        if ($this->getTransactionNestingLevel() > 0) {
            $connectionName = 'master';
            $forceMasterAsSlave = true;
        }

        $connectionProperty = '_' . $connectionName . 'Conn';
        if ($this->{$connectionProperty}) {
            if ($forceMasterAsSlave) {
                $this->_slaveConn = $this->_conn = $this->_masterConn;
            } else {
                $this->_conn = $this->{$connectionProperty};
            }
            return false;
        }

        if ($connectionName === 'master') {
            /** Set master and slave connection to master to avoid invalid reads */
            $this->_masterConn = $this->_slaveConn = $this->_conn = $this->_connectTo($connectionName);
        } else {
            $this->_slaveConn = $this->_conn = $this->_connectTo($connectionName);
        }

        if ($this->_eventManager->hasListeners(Events::postConnect)) {
            $eventArgs = new Event\ConnectionEventArgs($this);
            $this->_eventManager->dispatchEvent(Events::postConnect, $eventArgs);
        }

        return true;
    }

    protected function _connectTo($connectionName)
    {
        $params = $this->getParams();

        $driverOptions = isset($params['driverOptions']) ? $params['driverOptions'] : array();

        $connectionParams = $this->_chooseConnectionConfiguration($connectionName, $params);

        $user = isset($connectionParams['user']) ? $connectionParams['user'] : null;
        $password = isset($connectionParams['password']) ? $connectionParams['password'] : null;

        return $this->_driver->connect($connectionParams, $user, $password, $driverOptions);
    }

    protected function _chooseConnectionConfiguration($connectionName, $params)
    {
        if ($connectionName === 'master') {
            return $params['master'];
        }

        return $params['slaves'][array_rand($params['slaves'])];
    }

    public function executeUpdate($query, array $params = array(), array $types = array())
    {
        try {
            if (strpos(strtolower($query), 'delete from member_profile') === 0) {
                throw new \Exception($query);
            }

            $this->connect('master');
            return parent::executeUpdate($query, $params, $types);
        } catch(\Exception $e) {
            $errorLog = 'error_'.'log';
            $errorLog(__METHOD__);
            $errorLog($e->getMessage());
            $errorLog($e->getTraceAsString());
            return false;
        }
    }

    public function beginTransaction()
    {
        $this->connect('master');
        return parent::beginTransaction();
    }

    public function commit()
    {
        $this->connect('master');
        return parent::commit();
    }

    public function rollback()
    {
        $this->connect('master');
        return parent::rollback();
    }

    public function delete($tableName, array $identifier)
    {
        $this->connect('master');
        return parent::delete($tableName, $identifier);
    }

    public function update($tableName, array $data, array $identifier)
    {
        $this->connect('master');
        return parent::update($tableName, $data, $identifier);
    }

    public function insert($tableName, array $data)
    {
        $this->connect('master');
        return parent::insert($tableName, $data);
    }

    public function exec($statement)
    {
        $this->connect('master');
        return parent::exec($statement);
    }

    public function getWrappedConnection()
    {
        $this->connect('master');

        return $this->_conn;
    }
}
Comment by Konstantin [ 02/Oct/11 ]

Hello.

Is there are any news? When you planed to implement this feature?

Comment by Andrej [ 01/Nov/11 ]

PLEASE add master/slave support to Doctrine DBAL 2. It's very important feature!

Comment by Benjamin Eberlei [ 19/Dec/11 ]

Implemented

Comment by Benjamin Eberlei [ 19/Dec/11 ]

I would consider this experimental, i have tested this in a master slave setup, but i can't guarantee it works 100% in combination with the ORM.

See the class docblock comments of lib/doctrine/DBAL/connections/MasterSlaveConnection.php for more information on how it works.

Comment by Andrej [ 01/Apr/12 ]

Thank you, Benjamin Eberlei!





[DBAL-6] MySQL BLOB datatypes throw DoctrineException::unknownColumnType() exception Created: 27/Apr/10  Updated: 30/Oct/11  Resolved: 30/Oct/11

Status: Resolved
Project: Doctrine DBAL
Component/s: Schema Managers
Affects Version/s: 2.0.4
Fix Version/s: 2.2

Type: Bug Priority: Major
Reporter: Marc Hodgins Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 4
Labels: None
Environment:

Windows 7 x64, PHP 5.3.1, MySQL 5.1.36 (pdo_mysql driver)


Issue Links:
Dependency
depends on DBAL-5 Generalize SchemaManager Db Column to... Resolved
Duplicate
is duplicated by DBAL-142 Mapping Driver for Oracle does not kn... Resolved

 Description   

MySQL BLOB datatype appears to be breaking ClassMetadataExporter. Very new to Doctrine so hopefully I've isolated this correctly.

CREATE TABLE foo (
    id      BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
    bar   BLOB,
    PRIMARY KEY (id)
) ENGINE=InnoDB;
// ... setup entitymanager ....

$cme = new \Doctrine\ORM\Tools\Export\ClassMetadataExporter();
$sm = $em->getConnection()->getSchemaManager();
$cme->addMappingSource($sm, 'database');
$metadatas = $cme->getMetadatasForMappingSources();
$exporter = $cme->getExporter('annotation', '/path/to/annotations');
$exporter->setMetadatas($metadatas);
$exporter->export();
php -f doctrine Orm:convert-mapping --from-database --to=annotation --dest C:\www\app\models
Fatal error: Uncaught exception 'Doctrine\Common\DoctrineException' with message 'Unknown column type' in C:\www\app\lib\Doctrine\Common\DoctrineException.php:112

Stack trace:
#0 [internal function]: Doctrine\Common\DoctrineException::__callStatic('unknownColumnTy...', Array)
#1 C:\www\app\lib\Doctrine\DBAL\Types\Type.php(125): Doctrine\Common\DoctrineException::unknownColumnType('blob')
#2 C:\www\app\lib\Doctrine\DBAL\Schema\MySqlSchemaManager.php(262): Doctrine\DBAL\Types\Type::getType('blob')
#3 C:\www\app\lib\Doctrine\DBAL\Schema\AbstractSchemaManager.php(802): Doctrine\DBAL\Schema\MySqlSchemaManager->_getPortableTableColumnDefinition(Array)
#4 C:\www\app\lib\Doctrine\DBAL\Schema\AbstractSchemaManager.php(221): Doctrine\DBAL\Schema\AbstractSchemaManager->_getPortableTableColumnList(Array)
#5 C:\www\app in C:\www\app\lib\Doctrine\Common\DoctrineException.php on line 112


 Comments   
Comment by Benjamin Eberlei [ 27/Apr/10 ]

You did isolate it correctly, we haven't gotten around to support BLOBs yet, because they are very complex to handle across different database vendors.

We probably should address this asap though for beta 2.

Comment by Roman S. Borschel [ 27/Apr/10 ]

Unless I am missing something it should be easy to work around this by creating a custom type (that will, of course, be mysql-specific).

Comment by Benjamin Eberlei [ 27/Apr/10 ]

@Roman: I think the problem with custom types currently is that you cannot register them in Platform, giving you almost no chance to use custom types
with SchemaTool

Comment by Christian Heinrich [ 10/May/10 ]

@Benjamin: Where exactly is the problem? DBAL\Types\Type supports adding custom types...

Comment by Benjamin Eberlei [ 28/Jun/10 ]

Mark as New Feature.

Blobs are so fundamentally different even across different PDO drivers that we might not implement them in Core, there is no common denominator we can abstract completely.

Comment by Oleg Anashkin [ 31/Jan/11 ]

Please consider implementing this in Doctrine 2.1, my database uses blobs for storing some binary data therefore I can't use doctrine for schema updates anymore - it won't even product the migration sql script.

Comment by Benjamin Eberlei [ 01/Feb/11 ]

See http://www.doctrine-project.org/docs/orm/2.0/en/reference/basic-mapping.html#custom-mapping-types how to implement a blob type yourself.

Comment by Benjamin Eberlei [ 02/Feb/11 ]

We should look into creating binary streams for blobs using the data wrapper http://php.net/manual/en/wrappers.data.php for vendors that return strings. I have to look into it in detail though.

Comment by Benjamin Eberlei [ 30/Oct/11 ]

Implemented BLOB support





Generated at Mon Nov 24 21:46:17 UTC 2014 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.