[DBAL-1286] Add Cassandra driver Created: 25/Aug/15  Updated: 25/Aug/15

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

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


 Description   

http://cassandra.apache.org/






[DBAL-1081] Paginator - Query Limit for SQL Server - SqlServerPlatform.php Created: 16/Dec/14  Updated: 16/Jun/15

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

Type: Bug Priority: Major
Reporter: Maciej Grajcarek Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: dbal, dql, orderBy, sqlserver
Environment:

Windows



 Description   

Hi!
I have a problem with Query results limit when ordering by SUM of a field.

My query looks like this:

            SELECT ypk.name keyword, SUM(ypk.value) total
            FROM YpBundle:YellowPageKeyword ypk
              JOIN ypk.yellowpage yp
              JOIN yp.listing l
            WHERE l.customer = :customerId
              AND ypk.originDate >= :dateFrom
              AND ypk.originDate <= :dateTo
            GROUP BY ypk.nameCrc, ypk.name
            ORDER BY SUM(ypk.value) DESC

First I was catching following error:
message: "[Syntax Error] line 0, col 395: Error: Expected known function, got 'SUM'"
class: Doctrine\ORM\Query\QueryException

It only accourse if SUM is used in ORDER BY clause.

I have registered new class Sum which extends FunctionNode.

Now, query is build and executed but it has an error:

'SELECT * FROM 
     (SELECT y0_.name AS name_0, SUM(y0_.value) AS sclr_1, ROW_NUMBER() OVER (ORDER BY value) DESC) AS doctrine_rownum FROM yellowpage_keywords y0_ INNER JOIN yellowpages y1_ ON y0_.yellowpage_id = y1_.id INNER JOIN listings l2_ ON y1_.listing_id = l2_.id WHERE l2_.customer_id = ? AND y0_.origin_date >= ? AND y0_.origin_date <= ? GROUP BY y0_.name_crc, y0_.name) AS doctrine_tbl WHERE doctrine_rownum BETWEEN 1 AND 10 ORDER BY doctrine_rownum' with params ["111", "2013-01-01 00:00:00.000000", "2014-12-31 23:59:59.000000"]

The line :

ROW_NUMBER() OVER (ORDER BY value) DESC)

should look like

ROW_NUMBER() OVER (ORDER BY SUM(y0_.value) DESC)

In doModifyLimitQuery method I have modified:

                $pattern = sprintf('/%s\.%s\s+(?:AS\s+)?([^,\s)]+)/i', $column['table'], $column['column']);

to:

                $pattern = sprintf('/%s\.%s\s+(?:AS\s+)?([^,\s)]+)/i', str_replace('(', '\(', $column['table']), str_replace(')', '\)', $column['column']));

Now preg_match founds matching strings and OVER part of query is build correctly.

I checked other issues about this problem (which are marked as already fixed) and I have no idea why it's not working for me.

Thanks in advance!



 Comments   
Comment by Marco Pivetta [ 17/Dec/14 ]

Seems like a bit of information is missing: Is this issue related to the paginator API or not?

Comment by Maciej Grajcarek [ 17/Dec/14 ]

First of all - thank you for formatting my issue.
Secondly yes - issue is directly connected with paginator API.

Here is a code which should help you to replicate the problem:

            SELECT ypk.name keyword, SUM(ypk.value) total
            FROM YpBundle:YellowPageKeyword ypk
              JOIN ypk.yellowpage yp
              JOIN yp.listing l
            WHERE l.customer = :customerId
              AND ypk.originDate >= :dateFrom
              AND ypk.originDate <= :dateTo
            GROUP BY ypk.nameCrc, ypk.name
            ORDER BY SUM(ypk.value) DESC

        $dql = $this->getEntityManager()->createQuery($query);
        $dql
            ->setParameter('customerId', $customerId)
            ->setParameter('dateFrom', $dateFrom)
            ->setParameter('dateTo', $dateTo);
        $dql->setMaxResults(10);    

        $keywords = $dql->getArrayResult(); 
Comment by Marco Pivetta [ 17/Dec/14 ]

That doesn't involve the paginator, just DQL.

SUM() and computed values are not supported in the ORDER BY clause: you have to select them first. Try:

            SELECT ypk.name keyword, SUM(ypk.value) total
            FROM YpBundle:YellowPageKeyword ypk
              JOIN ypk.yellowpage yp
              JOIN yp.listing l
            WHERE l.customer = :customerId
              AND ypk.originDate >= :dateFrom
              AND ypk.originDate <= :dateTo
            GROUP BY ypk.nameCrc, ypk.name
            ORDER BY total DESC
Comment by Maciej Grajcarek [ 18/Dec/14 ]

If I will do it, it will result in a following query:

SELECT *
FROM (
	SELECT y0_.name AS name_0, SUM(y0_.value) AS sclr_1, ROW_NUMBER() OVER (ORDER BY sclr_1 DESC) AS doctrine_rownum 
	FROM yellowpage_keywords y0_
	INNER JOIN yellowpages y1_ ON y0_.yellowpage_id = y1_.id
	INNER JOIN listings l2_ ON y1_.listing_id = l2_.id
	WHERE l2_.customer_id = 111
		AND y0_.origin_date >= '2014-01-01'
		AND y0_.origin_date <= '2014-12-01'
	GROUP BY y0_.name_crc, y0_.name
) AS doctrine_tbl
WHERE doctrine_rownum BETWEEN 1 AND 10
ORDER BY doctrine_rownum

It's an incorrect query for an SQL Server. Take a look on this part:

ROW_NUMBER() OVER (ORDER BY sclr_1 DESC) AS doctrine_rownum

SQL Server do not support aliasing in OVER clause.

It should look like this, to work:

ROW_NUMBER() OVER (ORDER BY SUM(y0_.value) DESC) AS doctrine_rownum

It looks like this is the copy of this issue: http://www.doctrine-project.org/jira/browse/DBAL-788
I'm on doctrine version 2.5 which has patch from that issue included, but I have no idea why it's not working for me.

Comment by Steve Müller [ 24/Dec/14 ]

Maciej Grajcarek looks like it is an issue with your SUM function implementation. If you change your DQL to use ORDER BY COUNT(ypk.value) instead of ORDER BY SUM(ypk.value), does it work then? If so, there is something wrong with your SUM function and therefore not an issue with DBAL.

Comment by Steve Müller [ 24/Dec/14 ]

well forget about it I think I am wrong here.

Comment by Maciej Grajcarek [ 29/Dec/14 ]

Hi,
I will try to use COUNT as soon as I will be able to do that.

But I already tried other aggregation functions before and the result was exactly the same.

Comment by Luca Cerretani [ 16/Jun/15 ]

I get a similar error using this sql:

$sql = "SELECT table_one.id, table_one.number, table_two.name " . 
           "FROM table_one " .
	   "LEFT JOIN table_two	ON table_two.table_one_id = table_one.id " .
           "ORDER BY table_one.id DESC";

using the doModifyLimitQuery i get the uncorrect sql

SELECT * FROM (SELECT table_one.id, table_one.number, table_two.name, ROW_NUMBER() OVER (ORDER BY id DESC) AS doctrine_rownum  FROM table_one LEFT JOIN table_two ON table_two.table_one_id = table_one.id) AS doctrine_tbl WHERE doctrine_rownum BETWEEN 1 AND 1 ORDER BY doctrine_rownum

it should be

SELECT * FROM (SELECT table_one.id, table_one.number, table_two.name, ROW_NUMBER() OVER (ORDER BY table_one.id DESC) AS doctrine_rownum  FROM table_one LEFT JOIN table_two ON table_two.table_one_id = table_one.id) AS doctrine_tbl WHERE doctrine_rownum BETWEEN 1 AND 1 ORDER BY doctrine_rownum




[DBAL-1243] Unique Key on two columns overrules three column index causing drop index Created: 09/Jun/15  Updated: 09/Jun/15

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

Type: Bug Priority: Trivial
Reporter: Arkadiusz Rzadkowolski Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Running schema compare will result with index being returned for removal.

DROP INDEX OPB_BLG_IDX1 ON OPB_BLOGS;

The reason for that is that OPB_BLG_IDX1 matches two columns (BLG_DOMAIN, BLG_PATH) with unique key OPB_BLG_UK1. It skips check for last column (BLG_STATUS).

Shouldn't spansColumns method be run on same type of index only? Right now OPB_BLG_IDX1 is being removed since doctrine thinks it's overruled by unique key (and I don't think it should be treated that way).

Example annotation (problem is with OPB_BLG_UK1 & OPB_BLG_IDX1 as stated above):

/**
 * OpbBlogs
 *
 * @ORM\Table(name="OPB_BLOGS", uniqueConstraints={@ORM\UniqueConstraint(name="OPB_BLG_UK1", columns={"BLG_DOMAIN", "BLG_PATH"})},
 * indexes={
 *      @ORM\Index(name="OPB_BLG_IDX1", columns={"BLG_DOMAIN", "BLG_PATH", "BLG_STATUS"}),
 *      @ORM\Index(name="OPB_BLG_IDX2", columns={"BLG_USR_ID"}),
 *      @ORM\Index(name="OPB_BLG_IDX3", columns={"BLG_TYP_ID"}),
 *      @ORM\Index(name="OPB_BLG_IDX4", columns={"BLG_CAT_ID"}),
 *      @ORM\Index(name="OPB_BLG_IDX5", columns={"BLG_DOMAIN"}),
 *      @ORM\Index(name="BLG_CREATED_DATE", columns={"BLG_CREATED_DATE"}),
 *      @ORM\Index(name="BLG_ID", columns={"BLG_ID", "BLG_LAST_POST_ID"}),
 *      @ORM\Index(name="BLG_LAST_POST_DATE", columns={"BLG_LAST_POST_DATE"}),
 *      @ORM\Index(name="BLG_SLT_ID", columns={"BLG_SLT_ID", "BLG_DBNAME"})
 * })
 *
*@ORM\Entity
 */





[DBAL-1234] Additional slash in dbname when providing settings as URL without scheme Created: 21/May/15  Updated: 21/May/15

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

Type: Bug Priority: Minor
Reporter: Sebastian Krebs Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None

Issue Links:
Duplicate
duplicates DBAL-1238 [GH-863] Strip leading slash of datab... Open

 Description   

Hi,

I use https://github.com/realestateconz/MssqlBundle to connect to an MSSQL-database and I'd like to provide the connection parameters as URL. Because dblib is not a supported driver I setup the driverClass instead

driver_class:   \Realestate\MssqlBundle\Driver\PDODblib\Driver

So the corresponding URL would look like

//user:pass@127.0.0.1/dabasename

But now it tries to connect to the database /databasename instead of databasename. I can set an arbitrary scheme here as long as it exists and is supported (and is not SQLite)

mysqli://user:pass@127.0.0.1/dabasename

Now it works, but it's a hack.

It seems, that the issue is here
https://github.com/doctrine/dbal/blob/32b1a4f85a078f67752851c27be4065071db1f8b/lib/Doctrine/DBAL/DriverManager.php#L262
As long as there is no scheme the leading slash remains. I'd guess, that it should also take into account, that there might be no driver name, but a concrete driverClass instead

(!isset($url['scheme']) && !isset(isset($url['driverClass']))

?






[DBAL-95] Interbase/Firebird support Created: 26/Feb/11  Updated: 20/May/15

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

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


 Description   

Implemented support for Interbase/Firebird dialects



 Comments   
Comment by Andreas Prucha [ 17/Apr/15 ]

Hi all,

I've create a driver (or two) for Firebird.

The development branch is available at

https://github.com/helicon-os/doctrine-dbal.git DBAL-95-firebird

There are two versions of the driver: One is based on the ibase-api, there other on Firebird PDO.

I'd consider the ibase-version as almost finished, the PDO-Version is rather experimental.

Just send me a comment and maybe we can merge it into the official doctrine dbal (propably just the ibase-version, not the PDO-Version - at least not as long the driver problems are not fixed)

I've tested it with FB 2.5, but not with the upcoming FB 3 or Interbase.

___________________
ibase_firebird

The Ibase-Driver passes the complete Doctrine-Testsuite.

___________________
pdo_firebird

The PDO-Version does not, and it has some limitations which may be related to Firebirds PDO interface itself:

  • BLOBs: Runs into memory leaks if BLOBs are used quite quickly
  • PDO Firebird's transaction handling is quite strange and the reason why it does not pass the testsuite.
  • Nested Transactions (Savepoints): Fails despite Firebird supports them. -
  • Turns a negative signed 32bit integer into a positive unsigned, if the client is running a 64bit-system. I fixed this with a special IntegerType Class in a project, but that's a ugly workaround.
Comment by Andreas Prucha [ 17/Apr/15 ]

One more comment:

I am not sure how to handle one firebird-specificity: Firebird does not preserve the case of identity-names and converts them all-upper, unless they are quoted. The behaviour looks quite similar to Oracle.

Currently I do not normalize names as the Oracle-driver does, which leads to the problem, that they are all-upper in the database anyway, but automatically quoted keywords are lowercase.

Which behaviour would you guys prefere:

Normalize them All-Upper if not quoted (including keywords)? This would allow case-insensitive references in queries, because Firebird handles unquoted names as all-upper.
Quote everything to preserve case: Unfortunately this would require manual quoting in every query.

Personally I do not really like this all-upper-pattern, but having to quote every identifier everywhere looks even more cumbersome, so it's propably the best to follow the behaviour of the oracle driver and assume uppercase if not quoted.

Does any platform have configuration-options? It might be a solution to let the user decide about the naming, e.g.

setNamingConvention(ALL_UPPER | PRESERVE_CASE)

BTW - Is the doctrine-dev mailinglist gone? I wanted to send this there, but it came back with an error.

Andreas

Comment by Andreas Prucha [ 06/May/15 ]

Is it possible to setup a firebird test environment at travis?

Comment by Jürgen [ 20/May/15 ]

Hello Andreas,

good to hear about your work!

As a long time firebird user I can say that for me it is common to use column names case insensitive. So if you normalize all SQL commands to upper case (except quoted names) is the natural usage in firebird for me.

Jürgen





[DBAL-1207] Schema Update Issue with DBAL 2.5 Binary Type Created: 24/Apr/15  Updated: 18/May/15

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

Type: Bug Priority: Minor
Reporter: Alex Gurrola Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: schematool
Environment:

Ubuntu 14.04.2 LTS, Apache 2.4.7, PHP 2.5.9, MySQL 5.5, Symfony 2.6.6



 Description   

Every time I run a doctrine:schema:update command within Symfony, using DBAL 2.5, it tries to execute this SQL Query, every single time:

SQL Query
ALTER TABLE user_sessions CHANGE sess_id sess_id VARBINARY(128) NOT NULL;

The PHP Annotations I am using for this column is as follows:

Binary Column
/**
 * @var string
 *
 * @ORM\Column(name="sess_id", type="binary", length=128, nullable=false)
 * @ORM\Id
 * @ORM\GeneratedValue(strategy="IDENTITY")
 */
private $sessId;

It seems the binary type is somehow registering a change even though no change has actually been made. I updated to DBAL to 2.5 before getting the binary type supported by the doctrine:schema:update command.

Thanks in advance for any assistance in squashing this odd bug.

--Alex Gurrola



 Comments   
Comment by Nate Baker [ 15/May/15 ]

Do you intentionally have @ORM\GeneratedValue(strategy="IDENTITY"), or is that there from an auto import? I had the same problem but if I changed to strategy="NONE" it doesn't happen anymore. See this issue: http://www.doctrine-project.org/jira/browse/DBAL-353

Comment by Alex Gurrola [ 18/May/15 ]

It was an auto import. Your link resolved the issue, thanks.





[DBAL-1214] MySQL has gone away using ImportCommand Created: 29/Apr/15  Updated: 29/Apr/15

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

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


 Description   

Importing a fairly large SQL file (a MySQL dump) fails with a MySQL has gone away error.

When reading the ImportCommand code, I see that this issue is already "fixed" by checking if the connection is an instance of `\Doctrine\DBAL\Driver\PDOConnection`.

The problem is that I don't see how the connection could be an instance of this class since it doesn't extend `\Doctrine\DBAL\Connection`.

If I'm wrong, then I don't know how to configure my connection to extend the PDOConnection class. Thanks for your help on that






[DBAL-96] Make approach towards identifier quoting consistent Created: 26/Feb/11  Updated: 28/Apr/15

Status: Open
Project: Doctrine DBAL
Component/s: Platforms, Schema Managers
Affects Version/s: None
Fix Version/s: 2.6

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

Issue Links:
Duplicate
is duplicated by DBAL-120 MySql platform getAlterTableSQL does ... Resolved
Reference
relates to DBAL-45 Add CLI tool that checks for Reserved... Resolved
relates to DBAL-477 Just doublequote all schema names and... Open
is referenced by DBAL-40 Transparent table&column names escaping Open

 Description   
  • Make the use of `` a general approach for explicit quoting of identifiers
  • introduce AbstractPlatform::getRegularSQLIdentifierCase($identifier)
  • Introduce AbstractPlatform::isRegularIdentifier($identifier)
  • Fix Schema Assets not to lower-case, but to check for explicit quoting before.
  • Filter values of identifiers passed to all platform functions when they are used in information schema queries according to `` explicit quoting rules.

Problem: Schema is independent of a vendor, this means we have to pick a behavior, i propose SQL-92

This means:

  • strtoupper() ALL tables, column, index, foreign key names that are not quoted by ``
  • For any Quoted identifiers by `` the case is kept.
  • We can introduce a validator to detect a schema that cannot be implemented with a given vendor platform.

In conjunction with the SQL reserved keywords tickets we can then improve the DatabaseDriver considerably to detect identifier casings



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

Benjamin Eberlei this is an interesting approach and I like it. But I have some complaints about it.
1. I doubt users will be happy about forced default casing rules (ALL upper or ALL lower). Therefore we should think about adding a simple configuration option in DBAL allowing to override the default casing behaviour to the user's preference.
2. Using a consistent default casing means we ALWAYS have to quote identifiers as otherwise the underlying database could silently change the case again (don't know if this is an issue).
3. Introducing this approach in 2.x branch is a BC break as it breaks users' mixed-case identifier mappings.

For 2.x we should maybe at least make use of Identifier class throughout the platforms where necessary.

Comment by Sebastien Lavoie [ 28/Mar/15 ]

My 2 cents:

1. Users should not have to worry about platform-specific quoting when using the query builder or helpers, the DBAL should do that for you.
2. Users should be able to explicitly quote using a standard quote (`), the quote would then be converted to the platform’s quote upon SQL generation, without any case change.
3. DBAL should not needlessly quote, it adds bloat and it has been said in DBAL-40 that there is a performance hit.
4. DBAL should not change the case without the user’s knowledge.
5. A connection configuration option (normalize_case) could be added:
• uppercase: always convert unquoted identifiers to uppercase
• lowercase: always convert unquoted identifiers to lowercase
• platform: will use the default value for specific platform. For the case of case-sensitive platform, even when unquoted (MySQL on UNIX), do nothing.
• null (default): no normalization
6. Future versions of DBAL could change the default value to platform, but this would greatly reduce the risk of causing BC breaks at the beginning, giving time to test everything.
7. When using Doctrine\DBAL\Connection::query directly, you must do the quoting yourself since the SQL is executed directly.

Comment by Arthur Bodera [ 28/Mar/15 ]

Sebastien, ad 3. that is incorrect. Read the ticket more closely, look at the PR, look inside schema tool and platform classes. There is already a lot of quoting+unquoting being performed in 2.* and a lot of assumptions. Having quoting enabled across the board might actually increase performance in some cases, because there will be less scanning for keywords (see platform classes) and possibly less quoting/unquoting across Schema*.

The problem is, the quoting right now works in some places and in some platforms and is being performed only when schema/schematool/dql needs it, but is being ignored in all other cases. This means that columns like "group" or table names like "platform" will fail randomly depending on platform/rdbms you actually use. It's a nightmare with cross-platform apps and a struggle for single-platform apps, where your tables are named according to domain-rules and happen to overlap with some rdbms.

Quoting identifiers being "a bloat" is similar to saying, that implicit quoting values is a bloat. Although from security standpoint the former is much rarer, it's the same for portability and stability of the DBAL across platforms.

Comment by Andreas Prucha [ 28/Apr/15 ]

IMO the big problem is, that behaviour across the RDBMs may be completely different:

Some preserve case and are case-insenstive if not quoted (the nicest approach)
Some do not preserve case and normalize to lower or uppercase and are case-insensitive
And some do not preserve case and are case-sensitive (the worst)

The biggest issue arises if the DB needs to be used outside the Doctrine-Environment and all identifiers need to be quoted in statements.





[DBAL-1211] Wrapper Class should enforce a Interface not a Subclass Created: 27/Apr/15  Updated: 27/Apr/15

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

Type: Improvement Priority: Major
Reporter: Flavio Botelho Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: dbal


 Description   

We are creating a Wrapper Class to allow the use of the Oracle Proxy User feature. For that I need to Wrapper a Class around DBAL\Connection.
Unfortunely, the wrapper class needs to be a subclass of DBAL\Connection which doesn't make sense, there should exist an Interface and the wrapper class should be forced to implement that interface.

That way I don't need to create methods to call all DBAL\Connection methods thru polymorphism.






[DBAL-1206] Generating Table SQL without indexes is invalid if using AUTO_INCREMENT Created: 24/Apr/15  Updated: 24/Apr/15

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

Type: Bug Priority: Minor
Reporter: Markus Fasselt Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

MySQL (but maybe other database vendors too)



 Description   

Dumping the following table

CREATE TABLE `users` (
    `id` INT AUTO_INCREMENT NOT NULL,
    PRIMARY KEY (`id`)
);

with the following snippet (0 = NoIndexes)

$platform->getCreateTableSQL($table, 0);

results in

CREATE TABLE `users` (
    `id` INT AUTO_INCREMENT NOT NULL,
);

The problem is, that the table contains an AUTO_INCREMENT column which cannot be used without a primary key. But the primary key is skipped, as I skipped all indexes.

As this SQL is invalid, I suggest to skip the AUTO_INCREMENT argument, too, if the indexes are skipped. Alternatively, the Primary Key always has to be included.

What do you think? I can provide a fix, if you agree with me.






[DBAL-40] Transparent table&column names escaping Created: 05/Aug/10  Updated: 28/Mar/15

Status: Open
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: 2.3, 2.4, 2.4.1
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Jan Tichý Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 13
Labels: None

Issue Links:
Reference
relates to DBAL-96 Make approach towards identifier quot... Open

 Description   

Hello, I would like to re-open the discussion about automatic transparent escaping of all table/column names sent from DBAL to database. It was already discussed in http://www.doctrine-project.org/jira/browse/DDC-88 without any satisfactory result.

Why do I have to quote any reserved word used in table or column name? Why Doctrine doesn't do this automatically for all table and column
names used in generated SQL queries?

Before you start to explain how complicated it is and what problems you will be faced with, try to look at excellent DIBI database layer - how it acts in this way - it's behaviour is very cool. Unfortunally at the moment the full documentation is in czech only, but here is a brief automatic google-translation to english - http://dibiphp.com/en/quick-start.

My suggestion to Doctrine 2 ORM/DBAL solution is:

1. Developer should never care about any escaping or avoiding any reserved words - it is not his business, the DBAL shoult solve it transparently and safely.

2. So there should be no need and even no possibility to add any quotation chars in @column or @table annotations as well as in DQL queries. ORM layer has nothing to do with escaping, it is all a business of the DBAL layer. Current possibility for manual escaping the names in mentioned annotations is totally wrong and should be discontinued.

3. DBAL should escape ALL table and column names transparently and automatically. There should be ne option to enable or disable the escaping, there is no reason for disabling it.

4. The escaping should be performed just in the final translation of DBAL queries to native SQL query, not earlier. This is the right place to do that.

So what do you think about that?



 Comments   
Comment by Roman S. Borschel [ 05/Aug/10 ]

My point of view (and the reason for the current implementation) is as follows:

  • Using reserved words is bad practice.
  • Quoting everything is like hitting all the SQL with a huge big hammer just to hit the 1% of reserved words (which are again, bad practice), thus overkill.
  • Quoting everything bloats the generated SQL (just to hit the 1% of reserved words which are bad practice to begin with)
  • Quoting everything automatically is like hiding the fact from developers that they use reserved words, thus hiding a bad practice and silently encouraging usage of reserved words in new database schemas. This is not desirable.
  • Quoting reserved words has more effects than simply making the database "accept" that identifier. It affects the case-sensitivity and that in a very inconsistent way across databases and operating systems (See http://www.alberton.info/dbms_identifiers_and_case_sensitivity.html , especially the conclusion). You say there is no reason for disabling it but in fact there are a lot of reasons to do so, so many that it is disabled by default in MDB2 and discouraged to enable it.

So, supporting selective quoting in the name of a (slightly) better interoperability with legacy schemas looked (and still looks) like the best solution for us. The support is limited, explicit, does not require much implementation or overhead and does not unnecessarily bloat the SQL.

There is only one solution for reserved words: not using them. Quoting is a workaround, not a solution and especially not a good one.

ps: I really wish quoting reserved words would not be available in SQL It's not available in most programming languages and noone cares, people just don't use reserved words, because they simply can't.

Comment by Jan Tichý [ 05/Aug/10 ]

Hi Roman, thank you very much for your response! I storngly disagree with most of your points .

There is no doubt that using reserved words is bad practice - FROM THE VIEW OF DATABASE SYSTEM.

But we are discussing about ORM and DBAL. One of the biggest goals of ORM/DBAL is to provide transparent usage of the storage behind the scene. No matter if it is MySQL or PostgreSQL or even maybe something completely diferent.

The ORM/DBAL layer should prevent me from any specifics of particular storage as much as possible. I don't want to remember (and I never should to) that I cannot create entity Order because "order" is reserved word in some weird technology far away from me as ORM programmer.

It is strictly consistent with what you have written above in your PS - "It's not available in most programming languages and noone cares, people just don't use reserved words, because they simply can't" - just consider Doctrine 2 to be another programming language - and there is no real systematic reason in Doctrine 2 itself to prevent developers create entities named "Order".

Here is an analogy - It is the same as if you would say that you cannot use associative arrays in PHP because C-language or Assembler behind PHP doesn't support associative arrays. Yes, they don't support them but it is the responsibility of PHP to provide them. In the same way I don't want to respect this weird limitations of particular RDBMS behind Doctrine 2. This is Doctrine's responsibility to transparently cover the limitation.

Moreover, when list of registered keywords is different from one to the other RDBMS, so the naming of entities is strongly dependent on current database server.

Moreover, when I realize that I have used a registered keyword as lately as an error returns from database engine, not earlier.

I suppose here is probably no risk of SQL injection, but I feel the current Doctrine 2 acting to be "vulnerable" in very similar way, on principle. Simply - you are sending an unescaped piece of SQL query to the database without any warranty what it is. And sometimes it fails, sometimes not. From this view I don't consider overall escaping to be overkill at all, I consider it to be a necessity.

I am strongly convinced that developer working upon DBAL or even ORM layer should never think about such naming limitations and he even shouldn't know anything about reserved words in his particular DBMS.

Now to mentioned problems with case sensitivity. Resulting from the fact that Doctrine 2 entity names are case insensitive I belive that all table definitions and SQL queries comming from Doctrine 2 to database should act as case insensitive too. And that the only practicable way is to normalize (lowercase) all table and column names just on DBAL side before it is passed as SQL query to database.

Jan

Comment by Benjamin Eberlei [ 05/Aug/10 ]

There is actually a very good reason for not quoting. Oracle columns behave differently in their internal structure when escaped.

for example:

/**
  * @column(type="integer")
 */
private $foo;

With quoting it would lead to a column "foo" being lower-cased IN the database and even returned so from resultsets. Without casing it would be a column "FOO". We would essentially need to implement lots of glue code just to get this annoying Oracle feature to work and i think Postgres has the same with lower-cased columns.

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

@"Hi Roman, thank you very much for your response! I storngly disagree with most of your points"

I guess we can agree to disagree then

@"But we are discussing about ORM and DBAL. One of the biggest goals of ORM/DBAL is to provide transparent usage of the storage behind the scene. No matter if it is MySQL or PostgreSQL or even maybe something completely diferent."

Actually, no, "hiding" the storage completely from the developer is not the goal just as it is not the goal to "hide" SQL. There is an object model on one side and a relational database on the other side. The goal is to provide a mapping between them which is not the same as "hiding" one from the other. In order to create good applications that use ORM technology you need to know both very well, OOP and relational databases. The goal is not to make relational database knowledge "unnecessary". This only results in inefficient use of the databases. The goal is to give people who know both sides equally well a tool to map between the two. Not even "portability" between different relational database vendors is a main goal of an ORM technology, it is just obvious to provide assistance with that as part of the mapping.

@"and there is no real systematic reason in Doctrine 2 itself to prevent developers create entities named "Order".

Noone prevents you from naming domain classes anything you want. Class naming is different from table naming. That the table name defaults to the class name is just that, a default, that can and should be changed if necessary.

@"Moreover, when list of registered keywords is different from one to the other RDBMS, so the naming of entities is strongly dependent on current database server."

Correct, and if you want to create a portable application that works, and will be deployed on, a different set of vendors, you need to have some knowledge of these databases and consider their characteristics. An ORM/DBAL technology does not give you any guarantee for complete and transparent portability between vendors and especially not that it will perform equally well on all of them. The ORM/DBAL technology helps you for the most part in a lot of cases with portability issues but it is no free ticket.

@"I suppose here is probably no risk of SQL injection, but I feel the current Doctrine 2 acting to be "vulnerable" in very similar way, on principle. Simply - you are sending an unescaped piece of SQL query to the database without any warranty what it is. And sometimes it fails, sometimes not. From this view I don't consider overall escaping to be overkill at all, I consider it to be a necessity."

Do not confuse identifier quoting with quoting/escaping of special characters as it is used for security reasons on input. Identifier quoting is absolutely not a necessity, it is a workaround for using otherwise reserved words as schema element names. Speaking of goals, it is neither a "goal" of ORM/DBAL technology to completely remove the possibilities of SQL injections. You can't. It'll always be possible with wrong usage.

@"I am strongly convinced that developer working upon DBAL or even ORM layer should never think about such naming limitations and he even shouldn't know anything about reserved words in his particular DBMS."

And I am strongly convinced that a developer working with a DBAL/ORM should know the underlying databases pretty well.

I think you're really not aware of all the consequences it has across different database vendors to quote every identifier. If not for developers using Doctrine, you cause at least any developer or application pain that does not access the database through Doctrine and is thus feels the full pain of case-sensitivity and mandatory quoting you enforced on the whole schema. Ubiquitious access to the data is actually a strong point of a relational database and it is far from uncommon that the same database is accessed by many parties.

I think the approach taken by DIBI is a bad idea and even worse if there is no way to turn this behavior off. Do they have Oracle or DB2 users? I'm wondering what the sysadmins behind these databases might think if they see this quoting nightmare since to my knowledge this is considered bad practice among them as well.

Yes, we're disagreeing on many points but if you really think identifier quoting is a good idea then you're ignoring a whole lot of prior experience (not only mine).

Comment by Lukas Kahwe [ 05/Aug/10 ]

I was one of the lead developers of MDB2 and we just ran into tons of issues when we overly aggressively did identifier quoting by default. even the option caused lots of headaches. furthermore I agree that the ORM is not about turning an RDBMS into an Object Database, but instead to make a mapping possible. In this vain using reserved words or making all identifiers case sensitive will be a big pain for the people that do work one level lower aka the DBA's. heck even as a developer I frequently work on the DB's command line.

Now as for helping people prevent issues with reserved words. Back then I added some reserved word checking into MDB2_Schema. Obviously its hard to really keep track of all of the different reserved words for all RDBMS. Maybe its possible to work with this guy for this: http://www.petefreitag.com/item/290.cfm This way it could be possible to validate if the names chosen in the models will not cause issues with a certain list of RDBMS.

Comment by Benjamin Eberlei [ 07/Aug/10 ]

Reserved words checking sounds to be a fair compromise!

Comment by Jan Tichý [ 30/Aug/10 ]

Hello, thank you all for your responses.

This helped me understand much about Doctrine 2 basic objectives - especially that it is designed mainly to "make a mapping possible" only, not to be as much as possible transparent layer between database and application. And even if I don't like this conception (because I personally think ORM should provide all such features - like automatic reserved keywords escaping - to make the particular database as transparent as possible), at the same time I fully understand all metioned arguments for doing things in such way. Thank you again.

Comment by Damian Boune [ 17/Jan/11 ]

I would like to state an agreement with the OP.

I understand where there are difficulties in handling reserved words and backtick/quoting, and certainly one should always avoid the use of reserved words in their own schema designs. This is a given when one is able to exert control.

At present I am working on a project in which I am dealing with an outside database where I have no control over the schema, nor am I able to push the remote into making the most sensible changes to their schema. I must live with what they provide.

DBAL presents me with a set of invaluable tools that can not be used as-is, because it lacks the ability to handle quoting when generating schema sql. I'm sure there are some other places where I will find this lacking as well. This is disappointing.

Regardless of what we as developers should do when designing our own schema, we still need to be able to work and play with others who may not follow the same common sense conventions.

Edit:
My temporary quick solution to just "make it work", was to modify AbstractAsset::getQuotedName and force the use of $platform->quoteIdentifier. It did the trick for now until a more suitable solution presents itself.

Comment by Francesco Montefoschi [ 03/Feb/11 ]

"its hard to really keep track of all of the different reserved words for all RDBMS"

That's the main point for me.

Comment by Adrian Rudnik [ 26/Apr/11 ]

@Damian thanks for the hint. I just ran into a similar situation.

Not every project is a startup. I tried to use doctrine2 on a customers database for a small web ui. Well I told them to rename their `iso3166-1` table and `alpha-2` field, then we had a good laugh. We made the mapping possible but i'll remember the one thing i learned: doctrine did not help, guide, prevent or cared at all. It did not even hesitate to spew invalid sql snippets when asked to dump. Its okay for me, but i've expected something more resilient from a DBAL.

Comment by Robert (Jamie) Munro [ 02/Feb/13 ]

What do you mean by "Quoting everything is like hitting all the SQL with a huge big hammer"? Is there a performance hit?

I have always quoted all names when working with PostGres. Not quoting them has always felt like not quoting strings in PHP (e.g. $foo[bar] instead of $foo['bar'] because unless the string is keyword or defined as a constant somewhere, you don't need to (although you will get a "Use of undefined constant" warning). In the early days of PHP, not quoting array keys was common example practise.

Comment by Marco Pivetta [ 02/Feb/13 ]

If you want quoting by default on everything we have a quoting strategy (in ORM) that you can use. I don't think quoting everything by default is a viable solution. Back in `Zend_Db` times this was eating up a lot of performance for no real reason. Users having a clean schema without horrors like columns called `order` or `group` should not be penalized because of users not using valid naming schemes.

Comment by Steve Müller [ 24/Jun/13 ]

Hello, if I understand correctly, the issue of quoting reserved keywords automatically is solved in https://github.com/doctrine/dbal/pull/302. Besides reserved keywords you can still decide quoting or not quoting identifier manually by passing quotes to the identifier or not.

Comment by Arthur Bodera [ 26/Sep/13 ]

It's still broken in 2.4.

PR 302 only selectively fixes indexes, PK and FK, but ALTER and all CRUD will still fail (and schema tool will produce invalid sql).

There is no performance hit, as all operations already hit `DefaultQuoteStrategy`.

Currently you have the following workarounds:

  • selectively add `quoted=true` to table and column names (ugh)
  • replace `DefaultQuoteStrategy` with strategy that quotes all identifiers.

Here is a class you can use: https://gist.github.com/Thinkscape/6713196

Comment by Arthur Bodera [ 26/Sep/13 ]

QuoteStrategies are not used for ALTER queries. This means that using the EagerQuoteStrategy mentioned above won't fix invalid ALTER queries generated by schema tool.

For ALTER to work, we need this merged:

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

Comment by Doctrine Bot [ 26/Sep/13 ]

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

Comment by Sebastien Lavoie [ 28/Mar/15 ]

My 2 cents from DBAL-96:

1. Users should not have to worry about platform-specific quoting when using the query builder or helpers, the DBAL should do that for you.
2. Users should be able to explicitly quote using a standard quote (`), the quote would then be converted to the platform’s quote upon SQL generation, without any case change.
3. DBAL should not needlessly quote, it adds bloat and it has been said that there is a performance hit.
4. DBAL should not change the case without the user’s knowledge.
5. A connection configuration option (normalize_case) could be added:
• uppercase: always convert unquoted identifiers to uppercase
• lowercase: always convert unquoted identifiers to lowercase
• platform: will use the default value for specific platform. For the case of case-sensitive platform, even when unquoted (MySQL on UNIX), do nothing.
• null (default): no normalization
6. Future versions of DBAL could change the default value to platform, but this would greatly reduce the risk of causing BC breaks at the beginning, giving time to test everything.
7. When using Doctrine\DBAL\Connection::query directly, you must do the quoting yourself since the SQL is executed directly.

Comment by Arthur Bodera [ 28/Mar/15 ]

Sebastien, ad 3. that is incorrect. Read the ticket more closely, look at the PR, look inside schema tool and platform classes. There is already a lot of quoting+unquoting being performed in 2.* and a lot of assumptions. Having quoting enabled across the board might actually increase performance in some cases, because there will be less scanning for keywords (see platform classes) and possibly less quoting/unquoting across Schema*.

The problem is, the quoting right now works in some places and in some platforms and is being performed only when schema/schematool/dql needs it, but is being ignored in all other cases. This means that columns like "group" or table names like "platform" will fail randomly depending on platform/rdbms you actually use. It's a nightmare with cross-platform apps and a struggle for single-platform apps, where your tables are named according to domain-rules and happen to overlap with some rdbms.

Quoting identifiers being "a bloat" is similar to saying, that implicit quoting values is a bloat. Although from security standpoint the former is much rarer, it's the same for portability and stability of the DBAL across platforms.





[DBAL-1171] QueryBuilder - getForUpdateSQL Created: 13/Mar/15  Updated: 13/Mar/15  Resolved: 13/Mar/15

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

Type: Improvement Priority: Minor
Reporter: Bojidar Hristov Assignee: Marco Pivetta
Resolution: Can't Fix Votes: 0
Labels: QueryBuilder, lockhints


 Description   

It would be nice to be able to append FOR UPDATE in QueryBuilder.
Right now this is my workaround:

$qb = $connection->createQueryBuilder();
.......... qb stuffs .............
$stmt = $connection->executeQuery($qb->getSQL() . ' FOR UPDATE', $qb->getParameters());



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

This cannot be implemented, as FOR UPDATE is not cross-RDBMS compatible syntax.

Comment by Bojidar Hristov [ 13/Mar/15 ]

ORM supports it thru `$this->platform->getWriteLockSQL();`

Why DBAL not?

Comment by Marco Pivetta [ 13/Mar/15 ]

It's an implementation detail: each platform gets its own correct SQL generated. If you need platform-specific SQL, then don't use the query builder.





[DBAL-1164] Creating SQLite Connections via a URL Does Not Work Created: 07/Mar/15  Updated: 07/Mar/15

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

Type: Bug Priority: Minor
Reporter: Christopher Davis Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

When creating a SQL light connection put the URL path into the `dbname` param. But the SQLite driver doesn't using the `dbname` param: it uses the `path` parameter.

So doing this:

$conn = DriverManager::getConnection([
'url' => 'sqlite:////some/path/here',
]);

Generates a PDO DSN like this: `sqlite:`. The path is completely ignored.

See the driver code here: https://github.com/doctrine/dbal/blob/6b6143ba16e5f17242835910173c033a8f73f845/lib/Doctrine/DBAL/Driver/PDOSqlite/Driver.php#L81-L88

`DriverManager` either needs some logic to use the path when it sees a sqlite URL or the Driver itself should use `dbname` (eg. check path, check dbname, check memory).



 Comments   
Comment by Christopher Davis [ 07/Mar/15 ]

Same is true for memory databases. `dbname` is set, but the driver never checks it.





[DBAL-1058] It seems that MSSQL syntax was changed Created: 05/Dec/14  Updated: 29/Jan/15  Resolved: 12/Jan/15

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: 2.4, 2.5
Fix Version/s: 2.4.4, 2.6, 2.5.1

Type: Bug Priority: Blocker
Reporter: man4red Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: dbal, sqlserver

Issue Links:
Reference
is referenced by DBAL-1060 [GH-736] [DBAL-1058] Fix database and... Resolved
is referenced by DBAL-1061 [GH-737] [DBAL-1058] [2.4] Fix databa... Resolved

 Description   

I'm using dblib, MSSQL (2012).
So, problem is here:

doctrine-module orm:schema-tool:update --dump-sql

Doctrine\DBAL\Driver\PDOException: SQLSTATE[HY000]: General error: 20018 Invalid object name 'SYS.SCHEMAS'. [20018] (severity 16) [SELECT name FROM SYS.SCHEMAS WHERE name NOT IN('guest', 'INFORMATION_SCHEMA', 'sys')] in /var/www/domains/internal.dc.hayas.ru/data/partners.zf2/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php on line 106

So it seems, that problems is here:

Doctrine\DBAL\Platforms\SQLServerPlatform.php
At Line 1036

    public function getListNamespacesSQL()
    {
        return "SELECT name FROM SYS.SCHEMAS WHERE name NOT IN('guest', 'INFORMATION_SCHEMA', 'sys')";
    }

SQL Server >= 2005 uses sys.schemas (lowercase)

Maybe need to add to SQLServer2005Platform.php

SELECT name FROM sys.schemas ...

and also at line 1028 SQLServerPlatform.php

    public function getListDatabasesSQL()
    {
        return 'SELECT * FROM SYS.DATABASES';
    }

add to SQLServer2005Platform.php

    public function getListDatabasesSQL()
    {
        return 'SELECT * FROM sys.databases';
    }


 Comments   
Comment by Steve Müller [ 05/Dec/14 ]

man4red thanks for reporting. I'll have a look at it this evening. Weird that the functional tests pass though in my setup :S

Comment by Marco Pivetta [ 05/Dec/14 ]

Steve Müller please note that he is using dblib, which (afaik) we do not officially support.

Comment by man4red [ 05/Dec/14 ]

I've checked by direct query to SQL via SQL Management Studio.
Got multiple servers with a diffirent versions.

Here some test

QUERY:

 SELECT name FROM SYS.SCHEMAS WHERE name NOT IN('guest', 'INFORMATION_SCHEMA', 'sys') 

9.0.5069 (SQL Server 2005 Service Pack 4) PASS
10.50.4000.0 (2008 R2 SP2) FAIL
11.0.5058 (SQL Server 2012) FAIL

QUERY:

SELECT name FROM sys.schemas WHERE name NOT IN('guest', 'INFORMATION_SCHEMA', 'sys')

9.0.5069 (SQL Server 2005 Service Pack 4) PASS
10.50.4000.0 (2008 R2 SP2) PASS
11.0.5058 (SQL Server 2012) PASS

I've tested on 5 servers 11.0.5058 (SQL Server 2012).
QUERY:

SELECT name FROM SYS.SCHEMAS WHERE name NOT IN('guest', 'INFORMATION_SCHEMA', 'sys')

Failed on each of them

Other tests:

QUERY:

SELECT * FROM SYS.DATABASES

9.0.5069 (SQL Server 2005 Service Pack 4) PASS
10.50.4000.0 (2008 R2 SP2) PASS
11.0.5058 (SQL Server 2012) PASS

QUERY:

SELECT * FROM sys.databases

9.0.5069 (SQL Server 2005 Service Pack 4) PASS
10.50.4000.0 (2008 R2 SP2) PASS
11.0.5058 (SQL Server 2012) PASS

by the way - is it neccessary to query * from SYS.DATABASES ?

Doctrine\DBAL\Platforms\SQLServerPlatform.php

Line 1030

    public function getListDatabasesSQL()
    {
        return 'SELECT * FROM SYS.DATABASES';
    }

Maybe need to query only names? (name field)
Just asking

Comment by man4red [ 05/Dec/14 ]

According to tests I've added next code to SQLServer2008Platform.php

    /**
     * {@inheritDoc}
     */
    public function getListNamespacesSQL()
    {
        return "SELECT name FROM sys.schemas WHERE name NOT IN('guest', 'INFORMATION_SCHEMA', 'sys')";
    }

And modified my ZF2 application doctrine config config/autoload/doctrine.local.php (platform added):

return array(
    'doctrine' => array(
        'connection' => array(
            'orm_default' => array(
                'driverClass' => 'class to work with dblib',
                'params' => array(
                    'host' => 'hostname',
                    'port' => 1433,
                    'user' => 'user',
                    'password' => 'pass',
                    'dbname' => 'database',
                    'platform' => new Doctrine\DBAL\Platforms\SQLServer2012Platform()
                )
            )
        )
    )
);

Now I've got no issues with MSSQL 2012
I hope my fix was correct

Comment by Steve Müller [ 05/Dec/14 ]

Patch provided: https://github.com/doctrine/dbal/pull/736

Comment by Doctrine Bot [ 05/Dec/14 ]

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

Comment by man4red [ 05/Dec/14 ]

Dear friends,

I'm new here, and I don't know how all this works here, but can you help me?
As always when one bug fixed - another two produced

Now I've got another problem.
ZendDeveloperTool throws Exception

Uncaught exception 'PDOException' with message 'You cannot serialize or unserialize PDO instances'

of course because of my

    'platform' => new Doctrine\DBAL\Platforms\SQLServer2012Platform()

ok... my mistake

let's fix it in ZF2 way

    'platform' => 'Doctrine\DBAL\Platforms\SQLServer2012Platform'

Now we got another exception:

Doctrine\DBAL\DBALException: Invalid 'platform' option specified, need to give an instance of \Doctrine\DBAL\Platforms\AbstractPlatform.

let's look to doctrine\dbal\lib\Doctrine\DBAL\Connection.php Line: 387

    private function detectDatabasePlatform()
    {
        ...
        } elseif ($this->_params['platform'] instanceof Platforms\AbstractPlatform) {
            $this->platform = $this->_params['platform'];
        } else {
            throw DBALException::invalidPlatformSpecified();
        }
        ...
    }

So my question is

Can we implemet a feature and change this

    private function detectDatabasePlatform()
    {
        if ( ! isset($this->_params['platform'])) {
            $version = $this->getDatabasePlatformVersion();

            if (null !== $version) {
                $this->platform = $this->_driver->createDatabasePlatformForVersion($version);
            } else {
                $this->platform = $this->_driver->getDatabasePlatform();
            }
        } elseif ($this->_params['platform'] instanceof Platforms\AbstractPlatform) {
            $this->platform = $this->_params['platform'];
        } else {
            throw DBALException::invalidPlatformSpecified();
        }

        $this->platform->setEventManager($this->_eventManager);
    }

to this (or similar)

    private function detectDatabasePlatform()
    {
        if (! isset($this->_params['platform'])) {
            $version = $this->getDatabasePlatformVersion();

            if (null !== $version) {
                $this->platform = $this->_driver->createDatabasePlatformForVersion($version);
            } else {
                $this->platform = $this->_driver->getDatabasePlatform();
            }
        } elseif ($this->_params['platform'] instanceof Platforms\AbstractPlatform) {
            $this->platform = $this->_params['platform'];
        } elseif (is_subclass_of($this->_params['platform'], 'Doctrine\DBAL\Platforms\AbstractPlatform')) {
            $this->platform = new $this->_params['platform']();
        } else {
            throw DBALException::invalidPlatformSpecified();
        }

        $this->platform->setEventManager($this->_eventManager);
    }

or this problem is only mine and I need to fix it by my self and to write some forks/mods etc?

Thx for your help anyway

Comment by Marco Pivetta [ 05/Dec/14 ]

man4red that seems to be related with DBAL-1057 - I'll mark this issue as resolved.

Comment by man4red [ 05/Dec/14 ]

Marco Pivetta, thx! Is there planned some big reworking of this section, am I right?
Am I need to post my last comment to DBAL-1057 thread?

Comment by Marco Pivetta [ 05/Dec/14 ]

man4red this section needs some work for 2.5.1, yes. As for posting to DBAL-1057, please do, but only the bits that may be relevant and that you feel that add up to the discussion without cluttering it.

Comment by Doctrine Bot [ 12/Jan/15 ]

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

Comment by Marco Pivetta [ 12/Jan/15 ]

Fixed in DBAL-1060

Comment by Doctrine Bot [ 23/Jan/15 ]

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

Comment by Doctrine Bot [ 29/Jan/15 ]

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





[DBAL-4] missing column type "enum" Created: 27/Oct/09  Updated: 14/Jan/15  Resolved: 13/Apr/11

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

Type: New Feature Priority: Minor
Reporter: Christian Ehmig Assignee: Benjamin Eberlei
Resolution: Won't Fix Votes: 2
Labels: None

Attachments: Text File enum_type_patch.patch    
Issue Links:
Dependency
depends on DBAL-1116 [GH-774] Added SET and ENUM types for... Resolved
Reference
is referenced by DBAL-89 MySqlPlatform does not handle enum a... Resolved
is referenced by DBAL-504 DBAL Enum fields migration issue / Po... Resolved
is referenced by DDC-2469 SQLite handling for ENUM-Fields Resolved

 Description   

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

I've included a patch which enables the missing "enum" type in AnnotationDriver, SchemaTool and DBAL/Types. Currently, only the MySQL Platform is supported (others throw exceptions). Please have a look if you find this a possible solution. A new type "EnumType" has been added.

An example docblock syntax would be:

     /**
     * @Column(name="myenum", type="enum", values={"email","nickname"})
     */
    private $myenum;

patch attached.



 Comments   
Comment by Roman S. Borschel [ 27/Oct/09 ]

D2 has no enum type (because php has no enum type), we might need a new type class for this if necessary. Might be non-trivial.

Comment by Christian Ehmig [ 27/Oct/09 ]

Yes, a new type class is needed. It should be possible (like in D1) to configure the list of available enum elements.

example from D1 doc:

---
Test:
  columns:
    enumtest:
      type: enum
      values: [php, java, python]

Would be important regarding migration issues.

Comment by Christian Heinrich [ 13/Mar/10 ]

Roman, is your response to be considered a "we will work on this" or a "probably won't implement it". I'm asking because I was thinking whether I should get into this or not.

Comment by Benjamin Eberlei [ 14/Mar/10 ]

My take, given the flyweight architecture of our type-system this is only implementable with a specific Enum class in the userland. The only thing we could offer would be an abstract class to extend from. This would rather be a task for a Doctrine Extension in my opinion, or even a documentation/cookbook problem.

Comment by David Abdemoulaie [ 10/Apr/10 ]

I see this as a non-issue. It belongs in an extension. ENUM is specific to MySQL, and is one of the most misused columns.

Comment by Benjamin Eberlei [ 13/Jun/10 ]

Change to minor

Comment by Benjamin Eberlei [ 13/Apr/11 ]

See http://www.doctrine-project.org/docs/orm/2.0/en/cookbook/mysql-enums.html

That is everything we can provide.





[DBAL-89] MySqlPlatform does not handle enum and set data types Created: 10/Feb/11  Updated: 14/Jan/15  Resolved: 10/Feb/11

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

Type: Bug Priority: Major
Reporter: James Reed Assignee: Benjamin Eberlei
Resolution: Won't Fix Votes: 0
Labels: None

Attachments: File MySqlPlatform.php    
Issue Links:
Reference
relates to DBAL-4 missing column type "enum" Resolved
is referenced by DBAL-1116 [GH-774] Added SET and ENUM types for... Resolved

 Description   

If you do a reverse engineer of an existing database that includes enum and set columns the reverse engineer will fail. Ideally there could be a separate Doctrine type for these fields, but at a minimum it seems they should be treated as string values. I solved my reverse engineering problem by modifying the initializeDoctrineTypeMappings in the MySqlPlatform.php file (attached):

protected function initializeDoctrineTypeMappings()

{ $this->doctrineTypeMapping = array( 'tinyint' => 'boolean', 'smallint' => 'smallint', 'mediumint' => 'integer', 'int' => 'integer', 'integer' => 'integer', 'bigint' => 'bigint', 'tinytext' => 'text', 'mediumtext' => 'text', 'longtext' => 'text', 'text' => 'text', 'varchar' => 'string', 'string' => 'string', 'char' => 'string', 'date' => 'date', 'datetime' => 'datetime', 'timestamp' => 'datetime', 'time' => 'time', 'float' => 'float', 'double' => 'float', 'real' => 'float', 'decimal' => 'decimal', 'numeric' => 'decimal', 'year' => 'date', 'enum' => 'string', 'set' => 'string', ); }

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

There is a method on the platform "regsiterDoctrineMappingType" that modifies this array.

Enums and Sets cannot be generically supported by architectural choice.

Comment by James Reed [ 10/Feb/11 ]

Ah, didn't know about the regsiterDoctrineMappingType. Good solution. Thanks!

Comment by James Reed [ 10/Feb/11 ]

Actually, after searching the code the method is "registerDoctrineTypeMapping"





[DBAL-1062] upgrade from v2.4.3 to v2.5.0 is forcing recreating Indexes making Doctrine unusable Created: 05/Dec/14  Updated: 13/Jan/15  Resolved: 26/Dec/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: 2.5
Fix Version/s: 2.6, 2.5.1

Type: Bug Priority: Major
Reporter: gondo Assignee: Steve Müller
Resolution: Fixed Votes: 1
Labels: index, rename
Environment:

any


Issue Links:
Reference
is referenced by DBAL-1063 Exceptions from SchemaTool when runni... Resolved
is referenced by DBAL-1092 [GH-756] [DBAL-1062] Fix renaming ind... Resolved

 Description   

after executing 'composer update' i was upgraded to dbal v2.5.0
(im using "doctrine/orm": "~2.2,>=2.2.3" in composer.json)
im using Symfony 2.6.*

now when i try 'app/console doctrine:schema:update --dump-sql' i see that doctrine wants to recreate indexes on some tables for no practical reason
nothing changed in the code.

example:
DROP INDEX idx_a604da13a76ed395 ON table1;
CREATE INDEX IDX_B7E704F0A76ED395 ON table1 (user_id);
DROP INDEX uniq_b3319c7d77153098 ON table2;
CREATE UNIQUE INDEX UNIQ_C984F95777153098 ON table2 (code);

however when i try to execute this update, im getting this error:
General error: 1553 Cannot drop index 'IDX_A604DA13A76ED395': needed in a foreign key constraint

this essentially prevents me from using automatic doctrine database mapping or using migration tools.



 Comments   
Comment by Marco Pivetta [ 05/Dec/14 ]

Downgraded to "Major", as this doesn't prevent usage of the DBAL at runtime.

You can still upgrade those indexes manually after having removed the FKs (to re-add them later on).

Seems like a case sensitivity issue of your setup: consider adding environment details.

Comment by Steve Müller [ 05/Dec/14 ]

Which database vendor are you using? Also interestingly the indexes get recreated with a different name. Thought of case sensitivity, too. I think the comparator nevertheless has to be adjusted to compare with identical case on index names.

Comment by gondo [ 05/Dec/14 ]

well it IS preventing me from using doctrine as it is.
i just downgraded dbal to v2.4.3 by adding "doctrine/dbal": "2.4.*", to my composer.js and everything is working fine. by that i mean, no commands to drop and create indexes.

im using mysql Ver 14.14 Distrib 5.6.21, for osx10.10 (x86_64) using EditLine wrapper

im developoing on OSX 10.10 and production is running CentOS.
i know that OSX is using case insensitive file system (i had to deal with it in the past when i was deploying to production)
but this time there is NO change in my code. zero. nothing.

if there was case sensitivity changes in dbal itself, that might be the problem, however that is nothing i can fix.

i would love to upgrade those indexes manualy, however i have no idea how to.
should i change something in the code? indexes were created and named by doctrine, not by me.
if you recommend updating database, that seems to be failing. i assume dropping indexes on live data might cause problems.
or is it safe to just drop and create these indexes in mysql cmd?

Comment by gondo [ 05/Dec/14 ]

i can not drop those indexes directly in mysql, im getting erros:
ERROR 1553 (HY000): Cannot drop index 'IDX_A604DA13A76ED395': needed in a foreign key constraint

Comment by Steve Müller [ 05/Dec/14 ]

okay just checked, casing is not a problem as identifiers will be lowercased automatically in Doctrine\DBAL\Schema\Table for comparison.
Need further information about the underlying database being used...

Comment by Steve Müller [ 05/Dec/14 ]

gondo please for now don't try to solve the issue automatically because it looks like a real issue we need to figure out. Otherwise there will be little chance we get to know the real cause of the issue...

Comment by gondo [ 05/Dec/14 ]

@Steve Müller for now i've solved it by downgrading dbal to v2.4.*
do you need some more information from me?
unfortunately i can't give you all the code, company policy + its quite big. but i can dump you database schemas and entity declarations of affected tables if that will help. please let me know.

Comment by Steve Müller [ 05/Dec/14 ]

Hmm cannot reproduce the problem. What I did:

composer create-project symfony/framework-standard-edition path/

then added 'doctrine/dbal": "2.4.*"' to composer.json

composer install

then created entity with unique column name (to force auto index generation)

php app/console doctrine:database:create
php app/console doctrine:schema:create

then changed 'doctrine/dbal": "2.4."' to 'doctrine/dbal": "2.5."' in composer.json

php app/console doctrine:schema:update --force
Nothing to update - your database is already in sync with the current entity metadata.

Tried that with pdo_mysql on ubuntu 14.04 x86_64.

Comment by gondo [ 05/Dec/14 ]

were you creating some tables with foreign keys?

Comment by gondo [ 05/Dec/14 ]

here is the list of all indexes what tries to be recreated:
http://pastebin.com/nFYp6pnp

here are the definitions of some entities + their schemas and indexes from mysql:
notification_channel
http://pastebin.com/EfkcyUnf
http://pastebin.com/Ngd1Lkbe

online_payment_option
http://pastebin.com/R5waCF35
http://pastebin.com/ti4TzyKX

user_settings
http://pastebin.com/gxed5kjY
http://pastebin.com/EiCBWKNQ

i've also tried to specify index with custom name as per http://doctrine-orm.readthedocs.org/en/latest/reference/annotations-reference.html#annref-index
to prevent this index recreation but without no luck, it was ignored.
i've tried to change the definition of `online_payment_option` table like this:
@ORM\Table(name="online_payment_option", options=

{"collate"="utf8_unicode_ci", "charset"="utf8"}

, indexes={@ORM\Index(name="TEST", columns=

{"code"}

)})
but after trying schema:update im still getting the same output http://pastebin.com/nFYp6pnp

Comment by Steve Müller [ 12/Dec/14 ]

Okay I think I get the problem now. I don't get any suggested update statements when upgrading from a DBAL 2.4 created schema to DBAL 2.5.
I assume this is because even in DBAL 2.4 the indexes are created with the name your update command suggests. For example:

DROP INDEX idx_a604da13a76ed395 ON notification_channel;
CREATE INDEX IDX_B7E704F0A76ED395 ON notification_channel (user_id);

You have an index named idx_a604da13a76ed395 in your database, the index name DBAL generates is IDX_B7E704F0A76ED395. Even in 2.4 this is the name that is generated by DBAL. The reason why you get those update statements is because index names are compared since DBAL 2.5 as part of the new index renaming feature.
I guess that the index name generation has changed in an earlier version of DBAL (can't prove that right now). So you probably created the index with a much earlier DBAL version back then and now it wants to rename it. This should be a one time "upgrade" step.
The reason why manually defining an index in your entity with a custom name has no effect is because ORM's schema tool prefers auto generated indexes over custom indexes if both fullfill the same criteria. This is something to be fixed in ORM then.
The foreign key problem is indeed something we have to deal with in DBAL. The update schema command should create SQL to first drop FKs, then rename indexes and afterwards recreate FKs again.
Hope that helps for now. Sorry for the upgrade circumstances...

Comment by gondo [ 12/Dec/14 ]

thank you very much for looking into this and spending time on it!
it is very likely that those indexes were created in older version, however I'm 100% that it is not older than 1 year.

if i understand correctly, there are several things what needs to be fixed (manual overwriting of indexes and generating proper update schema command)

is this something what will be fixed? or does this fall into "edge case" bucket and will be left until more people experience same problem?
so far I'm fine staying on 2.4.3 but eventually i would like to upgrade. if the fix is planned, i can wait. if not, than i can create manual update now.

thanks one more time

Comment by Steve Müller [ 12/Dec/14 ]

I am already on that foreign key issue. As soon as that is fixed, the generated update SQL should be valid so that it can safely be run and you don't need to update your index names manually then. As what the manual index preference is concerned that needs to be fixed in ORM. I might also have a look into this issue afterwards. I think it won't take long until DBAL 2.5.1 as there is another critical issue that needs to be adressed sonner than later.
With 2.5.1 you should be safe to update your schema automatically.

Comment by gondo [ 12/Dec/14 ]

perfect!
thats much sooner than i expected
thanks again

Comment by Gábor Tóth [ 22/Dec/14 ]

This is a deal breaker for us. We cannot use 2.5 branch until it is not fixed.

Comment by Marco Pivetta [ 22/Dec/14 ]

Gábor Tóth you are not forced to upgrade for now: consider sending a patch if it is that critical to you.

Comment by Steve Müller [ 24/Dec/14 ]

Gábor Tóth I provide a patch here: https://github.com/doctrine/dbal/pull/756

Comment by Doctrine Bot [ 26/Dec/14 ]

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

Comment by gondo [ 13/Jan/15 ]

i've just updated to 2.5.1 and the problem remains

Comment by Steve Müller [ 13/Jan/15 ]

gondo can you please post the SQL created by the schema tool and the error you get? Thanks.

Comment by gondo [ 13/Jan/15 ]

same as on the beginning, basically nothing changed for me :/
http://pastebin.com/NqP9aEae

Comment by Steve Müller [ 13/Jan/15 ]

Do you get an error when executing the SQL? I can see that foreign keys are now dropped before dropping and recreating the index which is part of the patch. The reason why the schema manager is still outputting upgrade SQL was discussed here before (index name mismatch). However this should only happen once now and it should work without an error.

Comment by gondo [ 13/Jan/15 ]

ah i see.
i was expecting that there will be no SQL update needed after this patch, but now i understand what you mean.
i was only doing `app/console doctrine:schema:update --dump-sql`
after trying `app/console doctrine:schema:update --force` (on localhost only) everything seems to be fine

perfect! i will do some more testing, hopefully i ll not destroy production database with this

Comment by Steve Müller [ 13/Jan/15 ]

Unfortunately we cannot prevent SQL generation for users that have different index names in their database than those created by the mapping. Those users will have to "resync" index names once and should be fine afterwards. If we would not compare index names, the index renaming feature would not be possible.
You should be safe to run the SQL in production as it is just dropping and recreating indexes / foreign keys.





[DBAL-50] PgSQL driver does not create indexes on foreign key columns Created: 18/Aug/10  Updated: 09/Jan/15  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

Issue Links:
Reference
is referenced by DBAL-1063 Exceptions from SchemaTool when runni... Resolved
is referenced by DDC-3478 [GH-1239] Fix index duplication for u... Resolved

 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-1085] Custom Type Compare Fails To Generate Correct Migrations Created: 19/Dec/14  Updated: 24/Dec/14  Resolved: 24/Dec/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Schema Managers
Affects Version/s: 2.0, 2.1, 2.2, 2.3, 2.4
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Nicolas Vanheuverzwijn Assignee: Steve Müller
Resolution: Invalid Votes: 0
Labels: migrations
Environment:

Everywhere



 Description   

// From doctrine 2.1
public function diffColumn(Column $column1, Column $column2)
{
$changedProperties = array();
if ( $column1->getType() != $column2->getType() )

{ $changedProperties[] = 'type'; }

...
}
The $column1->getType() will return the underlying platform object but the $column2->getType() will return the custom object type.

Because of the way the php compare function works, a custom type will always generate a changed property over the type of a column.

http://stackoverflow.com/questions/26964367/symfony2-doctrine-custom-types-generating-unneeded-migrations/27557785#27557785



 Comments   
Comment by Steve Müller [ 24/Dec/14 ]

Nicolas Vanheuverzwijn I think you will have to mark your custom type as requiring a SQL comment, otherwise the schema manager cannot distinguish between DateTime type and your custom type because both map to the same native SQL type. See here:

https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Types/Type.php#L327-L340

You will have to add the following to your custom type implementation:

/**
 * {@inheritdoc}
 */
public function requiresSQLCommentHint(AbstractPlatform $platform)
{
    return true;
}

Also I think it might be required to give your custom type a distinct name like:

/**
 * {@inheritdoc}
 */
public function getName()
{
    return 'datetime_utc';
}
Comment by Steve Müller [ 24/Dec/14 ]

See also: http://doctrine-orm.readthedocs.org/en/latest/cookbook/custom-mapping-types.html

Comment by Nicolas Vanheuverzwijn [ 24/Dec/14 ]

Wow, I shall take a look at this. This might be it ! Thanks a lot for your reply.

Comment by Steve Müller [ 24/Dec/14 ]

You're welcome. Can you please report if that fixed your problem so we can closse the issue eventually? Thanks.

Comment by Nicolas Vanheuverzwijn [ 24/Dec/14 ]

Yes sir. The problem I have was that I am using doctrine 2.2. I shall migrate my stuff to doctrine 2.5 and use that feature.

Comment by Nicolas Vanheuverzwijn [ 24/Dec/14 ]

This feature is implemented in version >=2.3 of Doctrine/DBAL.

Comment by Steve Müller [ 24/Dec/14 ]

Yes. 2.2 is EOL anyways and I think 2.3 is now only getting security fixes so an upgrade to at least 2.4 is highly recommended.





[DBAL-1070] AzureSQL specificities are not taken into account Created: 11/Dec/14  Updated: 11/Dec/14

Status: Open
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: 2.5
Fix Version/s: 2.4.3

Type: Bug Priority: Major
Reporter: Nicolas Séverin Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: azure, dbal, sqlserver
Environment:

Azure website using an AzureSQL database (based on SQL Server 2012).



 Description   

In Azure SQL, table ‘sys.extended_properties’ does not exist.
But SQLAzurePlatform inherits from class SQLServerPlatform, which uses it.
The code in question is here /Doctrine/DBAL/Platforms/SQLServerPlatform.php#L845.

Modifications to this portion of code were made to handle comments on columns differently in doctrine/dbal 2.5, but it used to work in 2.4.3.



 Comments   
Comment by Marco Pivetta [ 11/Dec/14 ]

Reverted to priority Major





[DBAL-1055] doctrine:schema:update SchemaException Created: 04/Dec/14  Updated: 08/Dec/14  Resolved: 08/Dec/14

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

Type: Bug Priority: Minor
Reporter: Danilo Henrique Fonseca Menezes Assignee: Steve Müller
Resolution: Invalid Votes: 0
Labels: dbal, schematool


 Description   

I'm trying to run doctrine:schema:update

and a have been thrown this exception

[Doctrine\DBAL\Schema\SchemaException]
The table with name 'name.dbo' already exists.

There are at least two entities with the following mapping structure for the Table name:

/**
 * NotaLancamento
 *
 * @Table(name="name.dbo.notalancamento")
 * @Entity
 */
class NotaLancamento

I'm using MSSQL and the database_name parameter for the connection is a has a different name (for example, name2). In my project I need to access data on the database 'name' and 'name2' at the same time, and they both have the schema dbo, I've been trying to solve this problem for a while. I searched on stackoverflow but got no answers.

Any ideas about what should I do?



 Comments   
Comment by Danilo Henrique Fonseca Menezes [ 04/Dec/14 ]

Going up on the exception stack trace I found out that the
/Doctrine/DBAL/Schema/AbstractAsset.php in its _setName method introduces the problem:

protected function _setName($name)
    {
        if ($this->isIdentifierQuoted($name)) {
            $this->_quoted = true;
            $name = $this->trimQuotes($name);
        }
        if (strpos($name, ".") !== false) {
            $parts = explode(".", $name);
            $this->_namespace = $parts[0];
            $name = $parts[1];
        }
        $this->_name = $name;
    }

It assumes that the namespace+name of the table should have only one dot.

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

Danilo Henrique Fonseca Menezes DBAL always assumes that you operate on one database at the time. The Schema class refers to exactly one database. So you cannot map entities for multiple databases with the same entity manager / connection. This is currently not supported.

See also here: http://stackoverflow.com/questions/15389692/cross-database-joins-with-doctrine-in-php

We might reconsider supporting this in 3.x but we cannot add support for this in 2.x as it would have to many implications on all dependent projects. So closing this for now.

Comment by Danilo Henrique Fonseca Menezes [ 08/Dec/14 ]

Steve Müller, thank you for your information, I had already read the stackoverflow article you mentioned and I was trying to overcome the problem.

Anyway, thank you so much and I hope to see this feature on doctrine 3.

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

You're welcome. We might add more schema object layers in 3.0 to make things like this work. Basically what I want to have in 3.0 is the possibility to retrieve the complete schema objects that exist on a single physical database instance which can be queried with one connection and abstract that into different schema layers (table -> schema -> catalog -> cluster — according to the SQL-92 standard definition). But 3.0 is not planned yet so it will take awhile until this might be possible





[DBAL-131] Remove Static Types Created: 19/Jun/11  Updated: 04/Dec/14

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

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


 Description   

the static types should be removed and made to instances of types that can differ between platforms.

Following reasons:

1. Some vendors already convert values to PHP types, for example integers. Not converting again could save about 15% wall-time for integers for example.
2. Some vendors require different type code, this is currently handled by expensive if checks.
3. If you want to change a type for one vendor but also use another vendor in the same request, then you have a problem currently.
4. If types were platform aware then we could make registering custom types simpler.






[DBAL-1046] Broken link Created: 12/Nov/14  Updated: 02/Dec/14

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

Type: Task Priority: Minor
Reporter: ted bohus Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

On the website, the link to download Doctrine DBAL 2.3.5 doesn't work...

http://www.doctrine-project.org/downloads/DoctrineDBAL-2.3.5-full.tar.gz

Thanks



 Comments   
Comment by Steve Müller [ 02/Dec/14 ]

ted bohus for now please use this link: https://github.com/doctrine/dbal/archive/v2.3.5.zip
We are having a look into the issue.





[DBAL-152] Github-PR-49 by juokaz: Ignore sysdiagrams table from a list Created: 21/Aug/11  Updated: 02/Dec/14  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

Comment by Doctrine Bot [ 26/Nov/14 ]

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

Comment by Doctrine Bot [ 02/Dec/14 ]

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





[DBAL-1041] DBAL exception when detecting unknown database types is too vague Created: 09/Nov/14  Updated: 20/Nov/14  Resolved: 10/Nov/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Schema Managers
Affects Version/s: 2.4
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: Tom Vogt Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: None
Environment:

OS X 10.9



 Description   

Using Symfony, updating a schema with

app/console doctrine:schema:update --dump-sql

gives me this error after I updated Doctrine today:

  [Doctrine\DBAL\DBALException]                                                                           
  Unknown database type name requested, Doctrine\DBAL\Platforms\PostgreSQL92Platform may not support it.  

The exception message verbosity is insufficient.



 Comments   
Comment by Marco Pivetta [ 10/Nov/14 ]

Reverted to minor

Comment by Marco Pivetta [ 10/Nov/14 ]

The confusion here comes from your database type, which is indeed "name" in your case.

See https://github.com/doctrine/dbal/blob/a2e87c57a9843f07e8e6d6e57fe0fff965c0f4ac/lib/Doctrine/DBAL/Platforms/AbstractPlatform.php#L423 for reference.

Also, please take few moments more before opening an issue next time.
We are all doing what we can in our free time here, and raging doesn't help anyone.

Comment by Tom Vogt [ 10/Nov/14 ]

Sorry for the wording, I didn't intend to rage or insult anyone, I'm just very direct when I report a problem.

I'm not sure your assessment is correct. I do NOT have any database type called "name". I have a few fields with a name "name", but none where the TYPE is set to "name" (which would, obviously, be an invalid type).

for example, I have definitions like this:
<field name="name" type="string"/>

But nowhere in the code (verified by global search) is the TYPE ever set to "name".

Comment by Tom Vogt [ 10/Nov/14 ]

I was half-wrong there. I don't have any entity definitions with that type, but since I use PostGIS, there are a few views that use "name" as a column type.

using the undocumented schema_filter fixes it. Still, if this error would provide the table name, it would be a massive help. To find the problem, I had to put debug code into vendor/doctrine/dbal/lib/Doctrine/DBAL/Schema/AbstractSchemaManager.php

Comment by Marco Pivetta [ 11/Nov/14 ]

What can eventually be done is catching and re-throwing a more specialized exception in the location where it may occur. If you feel the need for it, then please open a pull request directly.

Comment by Jon West [ 20/Nov/14 ]

For those who are coming across this specific error and are using PostGIS, add this to your config in appropriate place.

doctrine:
dbal:
schema_filter: ^spatial_ref_sys





[DBAL-1023] inconsistent line-ending Created: 24/Oct/14  Updated: 05/Nov/14  Resolved: 05/Nov/14

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

Type: Improvement Priority: Trivial
Reporter: Dmitry Khlebnikov Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: coding-standards


 Description   

There are currently two files in the Git repository with DOS line endings. This is inconsistent with the rest of DBAL files in the repository and breaks Git when the DBAL repository is attached as a subtree to a project.

The files with DOS line endings are:

dbal/docs/design/AZURE_FEDERATIONS.md
dbal/tests/Doctrine/Tests/DBAL/Functional/Ticket/DBAL421Test.php



 Comments   
Comment by Steve Müller [ 26/Oct/14 ]

Patch provided in: https://github.com/doctrine/dbal/pull/706





[DBAL-879] Sequence default value [PGSQL] Created: 29/Apr/14  Updated: 26/Oct/14

Status: Open
Project: Doctrine DBAL
Component/s: Drivers, Schema Managers
Affects Version/s: 2.4.2
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Mohammad Niknam Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: autoincrement, postgresql, sequence
Environment:

ArchLinux
PostgreSQL 9.3.4



 Description   

Hi
I'm using dbal to generate schmea from database via Schema-Manager. The problem is that my primary field 'id' have default value of 'nextval('test1_id_seq'::regclass)' but when I retrive columns using Doctrine\DBAL\Schema\AbstractSchemaManager::listTableDetails() or Doctrine\DBAL\Schema\Table::getColumns() , default value of the column 'id' is null.
In Doctrine\DBAL\Schema\PostgreSqlSchemaManager::_getPortableTableColumnDefinition() method at line 292 default value replaced with null, I don't know why but I guess It's because Driver compatibility.
Also Doctrine\DBAL\Schema\Sequence has no method to retrieve that table.
So I don't have the default value (pointing at sequence) and I can't find out what Sequence is linked to this table either.



 Comments   
Comment by Steve Müller [ 26/Oct/14 ]

Can you please provide a code example of how you create table + sequence and retrieve it?





[DBAL-801] add SECOND, MINUTE, WEEK into DATE_SUB, DATE_ADD Created: 04/Feb/14  Updated: 26/Oct/14  Resolved: 26/Oct/14

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

Type: Improvement Priority: Minor
Reporter: gondo Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: None


 Description   

currently only HOUR, MONTH, YEAR options are implemented
would be nice to have all of them but for now at least the major one would be fine, so to complete the list, i would like to see:
SECOND, MINUTE, WEEK to be implemented

im not sure if all the platforms are capable of this, so if anyone can verify that would be great.
after that, implementation is simple copy/paste of existing code with very minor changes.



 Comments   
Comment by Steve Müller [ 24/Apr/14 ]

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

Comment by Doctrine Bot [ 16/May/14 ]

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

Comment by Steve Müller [ 26/Oct/14 ]

Fixed as of https://github.com/doctrine/dbal/commit/d12eb786f3148e099e9cd14c76fba6c179a24629





[DBAL-375] Warning "Udefined index dbname" while creating database with oci8 driver Created: 31/Oct/12  Updated: 26/Oct/14  Resolved: 26/Oct/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Drivers
Affects Version/s: 2.2.2, 2.3.1
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: pavel patrin Assignee: Steve Müller
Resolution: Invalid Votes: 1
Labels: dbname, oci8


 Description   

In config specified:

doctrine:
dbal:
driver: "oci8"
host: "localhost"
port: "1521"
dbname: "orcl50"
user: "SYSTEM"
password: "123456"
charset: UTF8

When i create database (with symfony 2, doctrine:database:create), got that error:

=====================================
Could not create database for connection named orcl50
Notice: Undefined index: dbname in /path/to/symfony/vendor/doctrine-dbal/lib/Doctrine/DBAL/Driver/OCI8/Driver.php line 67
=====================================

If i comment "unset($params['dbname'])" in CreateDatabaseDoctrineCommand.php:54 all works fine.



 Comments   
Comment by Kris Willis [ 13/Nov/12 ]

I'm experiencing the same issue and your fix appears to work for me too; thanks!

Comment by Benjamin Eberlei [ 20/Apr/13 ]

on Oracle CREATE DATABASE is actually a CREATE USER. I am not sure the command should allow to do this.

Comment by Steve Müller [ 26/Oct/14 ]

This is not a DBAL issue, it has to be fixed in DoctrineBundle.





[DBAL-1017] Altering a foreign key column is not done properly for MySQL Created: 21/Oct/14  Updated: 21/Oct/14

Status: Open
Project: Doctrine DBAL
Component/s: Schema Managers
Affects Version/s: 2.5, 2.4.3
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Christophe Coevoet Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: mysql, schematool


 Description   

Altering a foreign key column column (for instance to make it not-nullable) or the index of a foreign key does not work on MySQL (to be exact, it does not work on some MySQL setups, but I haven't found the config setting impacting it yet). Making it work requires dropping the foreign key before altering the column/index and readding it after



 Comments   
Comment by Steve Müller [ 21/Oct/14 ]

Christophe Coevoet DBAL-732 related?





[DBAL-335] Is MasterSlaveConnection implemented correctly - seems to overwrite master connection on transaction methods? Created: 31/Aug/12  Updated: 16/Oct/14  Resolved: 17/Sep/12

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

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

Issue Links:
Dependency
is required for DBAL-1006 [GH-690] Backport [DBAL-717] Fix bug ... Resolved

 Description   

Forgive me to doubt, but I think there may be a bug in MasterSlaveConnection.

It's easier to understand what I'm saying by debugging and tracing the flow, but I'll illustrate it with gists.

First, here is a simple service method to create a user. It opens up a transaction, persists the user, commits and returns. On error, if there is an active transaction, rollback. Here is the gist:

https://gist.github.com/3547674

The "$conn->beginTransaction();" line is where we trace through (the remainder of the service method is now irrelevant). Looking into MasterSlaveConnection.php, we see the method tries to connect to the master connection (call this point ###):

https://gist.github.com/3547720

Now looking in the next gist, we see what happens when "$this->connect('master');" is called. At this point it's not that interesting, the internal "$this->_conn" property is set to "master".

https://gist.github.com/3547750

Now here lies the bug I believe. "parent::beginTransaction();" is called. When looking into this method, we see that another call is made to connect but this time without "master" as the argument (i.e. connect to slave). This call to connect is made before incrementing the transaction nesting level.

https://gist.github.com/3547808

Now, I won't do another gist for "MasterSlaveConnection::connect", but if you refer to the file at line 13 https://gist.github.com/3547750#file_master_slave_connection.php, you will see that it checks the transaction nesting level and if it is there, forces master. However, we don't increment the level until after the method returns, so the slave is used. Ultimately, this results in the internal "$this->_conn" property set to the "slave" connection which violates our original action at ### above where we said we want to connect to "master".

Am I missing something here? Here is a gist the is a basic attempt at fixing this one method. It simply copies the code from the parent method except does not connect twice. I believe the same would have to occur for all the other methods unless it can be fixed once at the "MasterSlaveConnection::connect" level.

https://gist.github.com/3547880

I've just fleshed out "beginTransaction", "commit" and "rollBack" in "MasterSlaveConnection" by basically copying and pasting the code from the parent class and for my failing use case, this fixes the issue. However, it did require updating "Connection" slightly so that I had access to some private variables.



 Comments   
Comment by Lars Strojny [ 31/Aug/12 ]

This looks indeed like a bug. From a first glimpse the fix would be to use master, if master is already connected.

Comment by Benjamin Eberlei [ 05/Sep/12 ]

This only happens when "keepSlave" = true, because then the master is not written into the slave property aswell:

   } else {
     $this->connections['slave'] = $this->_conn = $this->connectTo($connectionName);
   } 

Are you using keepSlave = true?

Comment by Jonathan Ingram [ 05/Sep/12 ]

Yes I am. Does that render this moot or still a bug?

Comment by Benjamin Eberlei [ 06/Sep/12 ]

Its still a bug, but it helps to know why this happens.

Comment by Benjamin Eberlei [ 17/Sep/12 ]

Fixed in master and 2.3, can you test it?

Comment by Jonathan Ingram [ 19/Sep/12 ]

Thanks for doing this. I will test it shortly.

Comment by Ivan Andric [ 22/Sep/12 ]

Hi,

not sure if you managed to test this but now test on mysql database fails with results below.
Probably some typo.

There was 1 error:

1) Doctrine\Tests\DBAL\Functional\MasterSlaveConnectionTest::testKeepSlaveBeginTransactionStaysOnMaster
Exception: [Doctrine\DBAL\DBALException] An exception occurred while executing 'INSERT INTO master_slave_table (test_int) VALUES ' with params

{"1":30}

:

SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '30' for key 'PRIMARY'

With queries:
2. SQL: 'CREATE TABLE master_slave_table (test_int INT NOT NULL, PRIMARY KEY(test_int)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB' Params:

Trace:
/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/Connection.php:793
/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/Connections/MasterSlaveConnection.php:231
/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/Connection.php:539
/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/Connections/MasterSlaveConnection.php:285
/home/ivan/git/dbal2/dbal/tests/Doctrine/Tests/DBAL/Functional/MasterSlaveConnectionTest.php:92

/home/ivan/git/dbal2/dbal/tests/Doctrine/Tests/DbalFunctionalTestCase.php:73
/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/Connection.php:793
/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/Connections/MasterSlaveConnection.php:231
/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/Connection.php:539
/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/Connections/MasterSlaveConnection.php:285
/home/ivan/git/dbal2/dbal/tests/Doctrine/Tests/DBAL/Functional/MasterSlaveConnectionTest.php:92

Caused by
Doctrine\DBAL\DBALException: An exception occurred while executing 'INSERT INTO master_slave_table (test_int) VALUES ' with params

{"1":30}

:

SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '30' for key 'PRIMARY'

/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/DBALException.php:47
/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/Connection.php:786
/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/Connections/MasterSlaveConnection.php:231
/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/Connection.php:539
/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/Connections/MasterSlaveConnection.php:285
/home/ivan/git/dbal2/dbal/tests/Doctrine/Tests/DBAL/Functional/MasterSlaveConnectionTest.php:92

Caused by
PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '30' for key 'PRIMARY'

/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/Connection.php:786
/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/Connections/MasterSlaveConnection.php:231
/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/Connection.php:539
/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/Connections/MasterSlaveConnection.php:285
/home/ivan/git/dbal2/dbal/tests/Doctrine/Tests/DBAL/Functional/MasterSlaveConnectionTest.php:92





[DBAL-1005] Timezones of DateTime instances are ignored when persisting dates Created: 15/Oct/14  Updated: 15/Oct/14  Resolved: 15/Oct/14

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

Type: Bug Priority: Major
Reporter: Brent Shaffer Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

When a DateTime instance, e.g. "2011-02-16 00:00:00 America/New_York" is written into the DB, the timezone is ignored and only "2011-02-16" is persisted. When fetching the date, it is written into a DateTime with the server's timezone, resulting in for example "2011-02-16 00:00:00 Europe/Berlin" which is not correct!

To fix this issue, Doctrine should convert dates to the server's timezone (if their own timezone differs) before persisting them or before executing queries containing DateTime instances.



 Comments   
Comment by Brent Shaffer [ 15/Oct/14 ]

I would like to reopen this issue - Doctrine is expecting the incoming DateTime objects to have the system's default_timezone. If they do NOT use the default timezone (let's say they, instead use UTC), then the date is saved in the format of the default timezone anyway, and upon hydration, the UNIX timestamp changes.

I don't see how this could ever be considered expected behavior. Doctrine is essentially modifying the timestamp being persisted.

Doctrine should set the timezone of the DateTime object prior to persistence using the date_default_timezone_get() method. Either that, or the persisted string should contain the timezone identifier of the initial DateTIme object.

Comment by Marco Pivetta [ 15/Oct/14 ]

See http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/cookbook/working-with-datetime.html

The current DateTime type completely ignores timezones and we will keep it like that for now.

Comment by Brent Shaffer [ 15/Oct/14 ]

@Marco thank you for your quick reply. Can you help me understand why the decision was made to expect the timezone to be the default instead of just setting it to be that way before persistence? It seems like all these woes could have been easily avoided...

Comment by Marco Pivetta [ 15/Oct/14 ]

Brent Shaffer it was indeed a mistake to not use stricter rules on DateTime instances, but due to the amount of code depending on this behavior right now, we cannot change the Doctrine\DBAL\Types\DateTimeType anymore.

Instead, we may consider introducing a new UTC-based datetime-type for 3.x.

A change is not going to be applied on existing logic.





[DBAL-589] Doctrine\DBAL\Schema\Column::visit has an Invalid Type Hint Created: 27/Aug/13  Updated: 15/Sep/14  Resolved: 21/Nov/13

Status: Resolved
Project: Doctrine DBAL
Component/s: Schema Managers
Affects Version/s: 2.3.4
Fix Version/s: 2.3.5

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

$ php -v
PHP 5.4.15 (cli) (built: Aug 16 2013 15:38:16)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies
with Xdebug v2.2.1, Copyright (c) 2002-2012, by Derick Rethans

$ uname -a
Darwin chrispmg.local 11.4.2 Darwin Kernel Version 11.4.2: Thu Aug 23 16:25:48 PDT 2012; root:xnu-1699.32.7~1/RELEASE_X86_64 x86_64



 Description   

Column::visit typehints against a class that doesn't exist (`Doctrine\DBAL\Schema\Visitor`).

https://github.com/doctrine/dbal/blob/2.3/lib/Doctrine/DBAL/Schema/Column.php#L398

Looks like there's a `use` statement at the top of the file that imports the correct class: https://github.com/doctrine/dbal/blob/2.3/lib/Doctrine/DBAL/Schema/Column.php#L23






[DBAL-522] BC break : executeQuery with an array containing null value(s). Created: 20/May/13  Updated: 15/Sep/14  Resolved: 21/May/13

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: 2.3.4
Fix Version/s: 2.4, 2.3.5

Type: Bug Priority: Blocker
Reporter: lemeunier Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: dbal
Environment:

Mac OSX 10.8.3, Mysql 5.5.28, PHP5.4



 Description   

Hello, i have got an error with doctrine 2.3.4 when i try to run the following code :

 
    $conn->executeQuery(
        'INSERT INTO FOO (foo, bar) values (:foo, :bar)', 
         array('foo' => 1, 'bar' => null)
     );

Error : Value for :bar not found in params array. Params array key should be "bar"

This code worked with doctrine 2.3.3.

I think the error comes from the function 'extractParam' in SQLParserUtils.php (DBAL)

line 215 : if (isset($paramsOrTypes[$paramName]))

The key exists even if the value is null.
So it should be:

  if (array_key_exists($paramName, $paramsOrTypes)) 

I am not enough confident to try a PR.
Thanks in advance!



 Comments   
Comment by Marco Pivetta [ 20/May/13 ]

I suggested a hotfix at https://github.com/doctrine/dbal/pull/322

Comment by lemeunier [ 21/May/13 ]

Thanks for the hotfix.





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

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

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

Issue Links:
Dependency
depends on DBAL-731 [GH-465] [DBAL-423] Optimize non-nati... Resolved

 Description   

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

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



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

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

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

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

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

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

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

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

Comment by Marco Pivetta [ 28/Feb/14 ]

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

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

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

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

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

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

Comment by Doctrine Bot [ 10/Sep/14 ]

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

Comment by Marco Pivetta [ 10/Sep/14 ]

Resolved in DBAL-731





[DBAL-933] Get Statement Column Metadata Created: 05/Jul/14  Updated: 06/Jul/14

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

Type: New Feature Priority: Trivial
Reporter: Benoît Burnichon Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

It would be nice to have a utility method in \Doctrine\Dbal\Driver\ResultStatement to properly retrieve the result column names.

Currently, we have to rely on somthing like
$columnNames = array_keys($statement->fetch(\PDO::FETCH_ASSOC));

Problem: It does not work with empty result-sets, and more checks should be performed to handle these.

With PDO, http://www.php.net/manual/en/pdostatement.getcolumnmeta.php could be used to properly retrieve names.

For Sqlite3 it is easy, http://www.php.net/manual/en/sqlite3result.columnname.php

For Mysql, http://www.php.net/manual/en/mysqli-result.fetch-fields.php would do the trick






[DBAL-911] Property access not yet allowed in path/to/MysqliConnection.php Created: 21/May/14  Updated: 22/May/14  Resolved: 22/May/14

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

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


 Description   

Updated doctrine/dbal from 0a7df7c58aeab4d1cef55a78e5ca50299a12a62b to 2.5.0-beta3 and received the following warning:

PHP Warning:  Doctrine\DBAL\Driver\Mysqli\MysqliConnection::__construct(): Property access is not allowed yet in /path/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/Mysqli/MysqliConnection.php on line 60


 Comments   
Comment by Till [ 22/May/14 ]

This duplicates DBAL-912 and can be closed.





[DBAL-44] nullable is not working for all datatypes Created: 30/Aug/10  Updated: 16/May/14  Resolved: 30/Aug/10

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

Type: Bug Priority: Critical
Reporter: Daniel Freudenberger Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None

Attachments: Text File nullable.patch    
Issue Links:
Reference
is referenced by DDC-1045 Schema-tool update missbehavior: Not ... Closed

 Description   

The nullable=true annotation is ignored from at least following Types:

  • SmallIntType
  • DecimalType
  • BooleanType (not sure if nullable makes sense here)


 Comments   
Comment by Roman S. Borschel [ 30/Aug/10 ]

This looks like it has been fixed for a while already. See:

http://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Types/SmallIntType.php
http://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Types/DecimalType.php
http://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Types/BooleanType.php

Comment by Daniel Freudenberger [ 30/Aug/10 ]

I'll take a look at the master next time before submitting a bug report. Anyway I think it would be better to not fix bugs without an existing ticket for the fixed bug

Comment by Daniel Freudenberger [ 30/Aug/10 ]

has already been fixed





[DBAL-825] ALTER COLUMN on mssql is failing if default constraint is attached Created: 03/Mar/14  Updated: 08/May/14  Resolved: 08/May/14

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

Type: Bug Priority: Major
Reporter: Thomas Müller Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: None
Environment:

MSSQL


Issue Links:
Duplicate
is duplicated by DBAL-826 [GH-536] [WIP] unit test for DBAL-825 Resolved
is duplicated by DBAL-833 [GH-542] [DBAL-825] Drop default cons... Resolved

 Description   

Here is the unit test - implemented in class SchemaManagerFunctionalTestCase

 
    public function testChangeColumnsTypeWithDefault()
    {
        $table = new \Doctrine\DBAL\Schema\Table('column_change_type_test');
        $table->addColumn('id', 'integer', array('default' => 5));

        $this->_sm->createTable($table);

        $columns = $this->_sm->listTableColumns("column_change_type_test");
        $this->assertEquals(1, count($columns));
        $this->assertInstanceOf('Doctrine\DBAL\Types\IntegerType', $columns['id']->getType());

        $tableDiff = new \Doctrine\DBAL\Schema\TableDiff('column_change_type_test');
        $tableDiff->changedColumns['id'] = new \Doctrine\DBAL\Schema\ColumnDiff(
            'id', new \Doctrine\DBAL\Schema\Column(
                'id', \Doctrine\DBAL\Types\Type::getType('smallint'), array('default' => 5)
            ),
            array('type'),
            new \Doctrine\DBAL\Schema\Column(
                'id', \Doctrine\DBAL\Types\Type::getType('integer'), array('default' => '5')
            )
        );

        $this->_sm->alterTable($tableDiff);

        $columns = $this->_sm->listTableColumns("column_change_type_test");
        $this->assertEquals(1, count($columns));
        $this->assertInstanceOf('Doctrine\DBAL\Types\SmallIntType', $columns['id']->getType());
        $this->assertSame('', $columns['id']->getDefault());
    }

Causes following result

 
Exception : [Doctrine\DBAL\DBALException] An exception occurred while executing 'ALTER TABLE column_change_type_test ALTER COLUMN id SMALLINT NOT NULL':

SQLSTATE [42000, 5074]: [Microsoft][SQL Server Native Client 11.0][SQL Server]The object 'DF_A74995E2_BF396750' is dependent on column 'id'.
SQLSTATE [42000, 4922]: [Microsoft][SQL Server Native Client 11.0][SQL Server]ALTER TABLE ALTER COLUMN id failed because one or more objects access this column.

With queries:
5. SQL: 'ALTER TABLE column_change_type_test ALTER COLUMN id SMALLINT NOT NULL' Params: 
4. SQL: 'SELECT    col.name,
                          type.name AS type,
                          col.max_length AS length,
                          ~col.is_nullable AS notnull,
                          def.definition AS [default],
                          col.scale,
                          col.precision,
                          col.is_identity AS autoincrement,
                          col.collation_name AS collation,
                          CAST(prop.value AS NVARCHAR(MAX)) AS comment -- CAST avoids driver error for sql_variant type
                FROM      sys.columns AS col
                JOIN      sys.types AS type
                ON        col.user_type_id = type.user_type_id
                JOIN      sys.objects AS obj
                ON        col.object_id = obj.object_id
                JOIN      sys.schemas AS scm
                ON        obj.schema_id = scm.schema_id
                LEFT JOIN sys.default_constraints def
                ON        col.default_object_id = def.object_id
                AND       col.object_id = def.parent_object_id
                LEFT JOIN sys.extended_properties AS prop
                ON        obj.object_id = prop.major_id
                AND       col.column_id = prop.minor_id
                AND       prop.name = 'MS_Description'
                WHERE     obj.type = 'U'
                AND       (obj.name = 'column_change_type_test' AND scm.name = SCHEMA_NAME())' Params: 
3. SQL: 'ALTER TABLE column_change_type_test ADD CONSTRAINT DF_A74995E2_BF396750 DEFAULT 5 FOR id' Params: 
2. SQL: 'CREATE TABLE column_change_type_test (id INT NOT NULL)' Params: 

Trace:
C:\projects\doctrine\dbal\lib\Doctrine\DBAL\Connection.php:988
C:\projects\doctrine\dbal\lib\Doctrine\DBAL\Schema\AbstractSchemaManager.php:971
C:\projects\doctrine\dbal\lib\Doctrine\DBAL\Schema\AbstractSchemaManager.php:612
C:\projects\doctrine\dbal\lib\Doctrine\DBAL\Schema\SQLServerSchemaManager.php:232
C:\projects\doctrine\dbal\tests\Doctrine\Tests\DBAL\Functional\Schema\SchemaManagerFunctionalTestCase.php:621
C:\projects\doctrine\dbal\vendor\phpunit\phpunit\PHPUnit\Framework\TestCase.php:976
C:\projects\doctrine\dbal\vendor\phpunit\phpunit\PHPUnit\Framework\TestCase.php:831
C:\projects\doctrine\dbal\vendor\phpunit\phpunit\PHPUnit\Framework\TestResult.php:648
C:\projects\doctrine\dbal\vendor\phpunit\phpunit\PHPUnit\Framework\TestCase.php:776
C:\projects\doctrine\dbal\vendor\phpunit\phpunit\PHPUnit\Framework\TestSuite.php:775
C:\projects\doctrine\dbal\vendor\phpunit\phpunit\PHPUnit\Framework\TestSuite.php:745
C:\projects\doctrine\dbal\vendor\phpunit\phpunit\PHPUnit\TextUI\TestRunner.php:349
C:\Program Files (x86)\PHP\v5.3\pear\PHPUnit\TextUI\Command.php:176
C:\Users\deepdiver\AppData\Local\Temp\ide-phpunit.php:268
C:\Users\deepdiver\AppData\Local\Temp\ide-phpunit.php:506

#0 C:\projects\doctrine\dbal\vendor\phpunit\phpunit\PHPUnit\Framework\TestCase.php(946): Doctrine\Tests\DbalFunctionalTestCase->onNotSuccessfulTest(Object(Doctrine\DBAL\DBALException))
#1 C:\projects\doctrine\dbal\vendor\phpunit\phpunit\PHPUnit\Framework\TestResult.php(648): PHPUnit_Framework_TestCase->runBare()
#2 C:\projects\doctrine\dbal\vendor\phpunit\phpunit\PHPUnit\Framework\TestCase.php(776): PHPUnit_Framework_TestResult->run(Object(Doctrine\Tests\DBAL\Functional\Schema\SQLServerSchemaManagerTest))
#3 C:\projects\doctrine\dbal\vendor\phpunit\phpunit\PHPUnit\Framework\TestSuite.php(775): PHPUnit_Framework_TestCase->run(Object(PHPUnit_Framework_TestResult))
#4 C:\projects\doctrine\dbal\vendor\phpunit\phpunit\PHPUnit\Framework\TestSuite.php(745): PHPUnit_Framework_TestSuite->runTest(Object(Doctrine\Tests\DBAL\Functional\Schema\SQLServerSchemaManagerTest), Object(PHPUnit_Framework_TestResult))
#5 C:\projects\doctrine\dbal\vendor\phpunit\phpunit\PHPUnit\TextUI\TestRunner.php(349): PHPUnit_Framework_TestSuite->run(Object(PHPUnit_Framework_TestResult), false, Array, Array, false)
#6 C:\Program Files (x86)\PHP\v5.3\pear\PHPUnit\TextUI\Command.php(176): PHPUnit_TextUI_TestRunner->doRun(Object(PHPUnit_Framework_TestSuite), Array)
#7 C:\Users\deepdiver\AppData\Local\Temp\ide-phpunit.php(268): PHPUnit_TextUI_Command->run(Array, true)
#8 C:\Users\deepdiver\AppData\Local\Temp\ide-phpunit.php(506): IDE_Base_PHPUnit_TextUI_Command::main()
#9 {main}



 Comments   
Comment by Thomas Müller [ 03/Mar/14 ]

Possible solution: http://www.select-sql.com/mssql/how-to-alter-column-with-default-constraint-in-mssql.html

Comment by Thomas Müller [ 03/Mar/14 ]

Here is the unit test: https://github.com/DeepDiver1975/dbal/commit/53238301f7e124d31232e9b3eab774c32c9e04c4

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

Thomas Müller Thanks for reporting. Which version of SQL Server is affected by this?

Comment by Thomas Müller [ 03/Mar/14 ]

SQL Server 2012 Express Edition

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

Fixed in commit: https://github.com/doctrine/dbal/commit/171a8762673ee61a89e3d6ce891cd2b475e7b5f7





[DBAL-834] SQLServer modifyLimitQuery does not work with aggregate functions in ORDER BY Created: 10/Mar/14  Updated: 05/May/14  Resolved: 05/May/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: 2.4.2
Fix Version/s: 2.5

Type: Bug Priority: Major
Reporter: Francesco Montefoschi Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: paginator
Environment:

SQL Server 2008 SP3


Issue Links:
Duplicate
duplicates DBAL-788 ORDER BY with function COUNT() fails Resolved
is duplicated by DBAL-875 [GH-573] [DBAL-834] Fix order by with... Resolved

 Description   

Starting with Doctrine 2.4, the `modifyLimitQuery` method does not work anymore with query using ORDER BY MAX(...)
See this example:

$sql = "SELECT MAX(heading_id) aliased, code
	FROM operator_model_operator
	GROUP BY code
	ORDER BY MAX(heading_id) DESC
";
$sql = $this->em->getConnection()->getDatabasePlatform()->modifyLimitQuery(
	$sql, 1, 0
);

Doctrine generates this SQL, which is invalid:

SELECT * FROM (SELECT MAX(heading_id) aliased, code
, ROW_NUMBER() OVER (ORDER BY MAX(heading_id) AS doctrine_rownum FROM operator_model_operator GROUP BY code) DESC
) AS doctrine_tbl WHERE doctrine_rownum BETWEEN 1 AND 1

The ORDER BY in moved into the OVER(), but the `preg_replace` in SQLServerPlatform.php stops to replace at the closing ")".



 Comments   
Comment by Francesco Montefoschi [ 10/Mar/14 ]

It is not possible to write `ORDER BY aliased` because it leads to a syntax error in SQL Server.

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

Francesco Montefoschi There have been some modifications to the modifyLimitQuery() method in SQL Server lately for 2.5 which address some problems with subqueries and aggregate functions. Not sure if that might already solve your issue. Can you please check if the problem also exists in the current master branch of DBAL?
See commit: https://github.com/doctrine/dbal/commit/9f3cb437c0f491599de4e1bd847235965f98ffd4

Comment by Francesco Montefoschi [ 11/Mar/14 ]
  - Removing doctrine/common (v2.4.1)
  - Installing doctrine/common (2.4.x-dev 9a7e20e)
    Cloning 9a7e20e779360f3b8a02c27a89d47d5a6fdce8d1

  - Removing doctrine/dbal (v2.4.2)
  - Installing doctrine/dbal (dev-master c61361d)
    Cloning c61361d8fcf65a977d8610ba78eb542a1d2f44b4

  - Removing doctrine/orm (v2.4.2)
  - Installing doctrine/orm (2.4.x-dev a949e87)
    Cloning a949e87ca88299cde368d2b574740753526b62c9

Same issue.

Comment by Flip [ 14/Mar/14 ]

on this line here https://github.com/doctrine/dbal/blob/9f3cb437c0f491599de4e1bd847235965f98ffd4/lib/Doctrine/DBAL/Platforms/SQLServerPlatform.php#L1164

try the following stuffs:

Puts "DESC" in a second capturing group (closer to the original regex, but not sure why you want to do this)
/ORDER\s+BY\s+([^)(]*(?:\(\w+\))?)(.*)/

Includes "DESC" in the first capturing group
/ORDER\s+BY\s+([^)(]*(?:\(\w+\))?.*)/

Same as last one, except this one stops capturing when it hits a ")" after "DESC"
/ORDER\s+BY\s+([^)(]*(?:\(\w+\))?[^)]*)/
Comment by M.K. [ 21/Mar/14 ]

This not only affects Queries with aggregate functions, but every Query that uses a limit and order by an entity-field alias.

Try this Testcase:

$query = $this->em->createQuery("
	SELECT a.id AS test
	FROM prim\\entity\\Article a
	ORDER BY test ASC
");
$query->setMaxResults(10);
echo "<h3>DQL</h3>";
var_dump($query->getDQL());
echo "<br><h3>SQL</h3>";
var_dump($query->getSQL());
echo "<br><h3>Result</h3>";
var_dump($query->getResult());
Comment by Flip [ 21/Mar/14 ]

The test case is incomplete as we don't have `kare\\entity
Article`. Please try the 3 proposed solutions and show the results from those adjustments.

Comment by M.K. [ 21/Mar/14 ]

This is just a sample Query for illustration. Replace it with whatever Entity you like.

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

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

Francesco Montefoschi Flip M.K. please review.

Comment by Francesco Montefoschi [ 28/Apr/14 ]

Hi Steve,

I tried 2.5.*@dev now and everything works for me.
About the code, I am not a regexp guru.

Just for review purpose, can you explain this regexp?
https://github.com/deeky666/dbal/commit/df1f3e4ce13eed6d0a406f34ea3174711531edae#diff-8a544d213159863ef39497f4b139b420R1155

Thank you.

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

The regex replaces the ORDER BY including nested parentheses expressions (uses recursion for that) until a terminating sequence is detected (for example a closing parenthesis that has no corresponding opening parenthesis from a previous ORDER BY expression.
This might not be perfect and complete but it is an improvement. It does not stop matching after the first closing parenthesis found.
Please note that the PR has not been merged yet so I am not sure whether you had the patch applied in your 2.5.*@dev version constraint.

Comment by Francesco Montefoschi [ 29/Apr/14 ]

Thank you Steve. I confirm you I tested your code (manually copied and pasted your patch to SQLServerPlatform in 2.5.*@dev ).
Maybe it is not perfect, but surely a huge improvement.

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

Alright. Thanks for testing.

Comment by M.K. [ 02/May/14 ]

I've had no time for testing this yet, but i read your code changes and i think this is definitely a big step forward. But it would be a lot nicer if you could always ORDER BY an alias in DQL. DBAL's goal is abstract away database specific language and for now users still have to worry about the Platform while writing DQL queries with ORDER BY :/

Comment by Steve Müller [ 02/May/14 ]

I'm not sure if I understand correctly. Can you please give an example of what you mean? It sounds like it's another issue?

Comment by M.K. [ 02/May/14 ]
SELECT MAX(heading_id) aliased, code
FROM operator_model_operator
GROUP BY code
ORDER BY aliased DESC

This Query won't work with modifyLimitQuery

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

M.K. Okay I think I get what you mean but that is another issue IMO. There should be a new ticket for this.

Comment by Francesco Montefoschi [ 05/May/14 ]

Can we merge this in master/2.5?

Comment by Doctrine Bot [ 05/May/14 ]

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

Comment by Steve Müller [ 05/May/14 ]

Fixed in commit: https://github.com/doctrine/dbal/commit/4a7ff71ec3b57af7d70f1180897502f8a156d59b





[DBAL-214] Unable to use PDO::FETCH_CLASS with a call to fetch() Created: 30/Jan/12  Updated: 17/Apr/14  Resolved: 05/May/12

Status: Resolved
Project: Doctrine DBAL
Component/s: Drivers
Affects Version/s: 2.0.0-BETA2, 2.0.0-BETA3, 2.0.0-BETA4, 2.0.0-RC1-RC3, 2.0-RC4, 2.0-RC5, 2.0, 2.0.1, 2.0.2, 2.0.3, 2.0.4, 2.0.5, 2.0.6, 2.0.7, 2.0.8, 2.1, 2.1.1, 2.1.2, 2.1.3, 2.1.5, 2.1.6, 2.2-BETA1, 2.2-BETA2, 2.2-RC1/RC2, 2.2.0-RC3, 2.2, 2.2.1, 2.2.2, 2.3, 2.5
Fix Version/s: 2.3

Type: Improvement Priority: Minor
Reporter: Andy Leon Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 1
Labels: None


 Description   

EDITED: 2nd attempt to describe this - first one was confusing.

I don't understand why the setFetchMode() method of Doctrine\DBAL\Driver\PDOStatement drops any arguments passed to it. It means that PDO::FETCH_CLASS cannot be used with calls to fetch() and no warning is given until the point when the underlying \PDOStatement complains that no class has been specified.



 Comments   
Comment by Antoine Froger [ 03/Feb/12 ]

In Doctrine/DBAL/Statement.php the 2nd and 3rd arguments of setFetchMode are dropped too.

Error message example when PDO::FETCH_CLASS is used as the first argument of setFetchMode:
$stmt->setFetchMode(PDO::FETCH_CLASS | PDO::FETCH_PROPS_LATE, 'ClassName');
display the error: PDOException: SQLSTATE[HY000]: General error: fetch mode requires the classname argument

Comment by Fabien Potencier [ 05/May/12 ]

This regression was introduced here: https://github.com/doctrine/dbal/commit/f4acc79a3e91059a932d7a2d43309f6f8f65fa59

It breaks some of my websites when upgrading DBAL. So, this is not an improvement but a regression bug.

Comment by Benjamin Eberlei [ 05/May/12 ]

Yes, i have to change this again.

The problem is its complex to support the 2nd/3rd arguments in the statement caching layer, i will just throw an exception for now and add an improvement ticket.

Comment by Benjamin Eberlei [ 05/May/12 ]

Fixed

Comment by Benjamin Eberlei [ 05/May/12 ]

https://github.com/doctrine/dbal/commit/d3930dcdb89cc818798c8f13e4126f76cf82ef8b





[DBAL-244] Shema Tool is not working after DBAL-177 for postgresql (mysql working like before) Created: 25/Mar/12  Updated: 17/Apr/14  Resolved: 05/May/12

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

Type: Bug Priority: Critical
Reporter: Margus Sipria Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None
Environment:

Ubuntu 10.10, Zend Server 5.5.0 with PHP 5.3.8



 Description   

After trying to upgrade 2.2.0 i found that schema tool wasn't working, so I switched back to 2.1.6, same thing with 2.2.1 and no bug report, so this is wats going on.

./doctrine orm:schema-tool:update --dump-sql # this will show full create table for schema even if tables are all ready there.

After git bisectin Doctrine ORM project i found that commit ea5108ea0f35fc0f7ed3a740995a590926045c6e wast to blame, but that was only submodule update so made bisect for Doctrine DBAL:

537de7ea6a34edbcc40bc6ca92e0a3f816b59330 .. 4410e4cec20b0f1f209578320e5b7d111e90c2a0 founding that 1ae87bf3e3ba93cb579a2a092b06b5a09b316542 was the problem.

[margus@laptop doctrine-dbal ((4410e4c...))]$ git reset --hard 1ae87bf3e3ba93cb579a2a092b06b5a09b316542
HEAD is now at 1ae87bf DBAL-177 - Make sure schema.table syntax is supported in Assets for quoted assets
[margus@laptop doctrine-dbal ((1ae87bf...))]$ git submodule update --recursive
Submodule path 'lib/vendor/doctrine-common': checked out 'd6e4c8b22af9800db4fd9d679ce98538da028168'

    1. shema tool printing full schema

[margus@laptop doctrine-dbal ((1ae87bf...))]$ git reset --hard HEAD^1
HEAD is now at bb84496 DBAL-144 - Dont throw exception when no primary key exists
[margus@laptop doctrine-dbal ((bb84496...))]$ git submodule update --recursive

    1. works fine

[margus@laptop build (master)]$ ./doctrine orm:schema-tool:update --dump-sql
Nothing to update - your database is already in sync with the current entity metadata.

with commit 1ae87bf3e3ba93cb579a2a092b06b5a09b316542 schema starts with 3 NULL lines, and then schema, with 2.2.0, extra "NULL" lines aren't there anymore.

Using MySQL there isn't any problem, but with PostgreSQL (i have 8.4.11) this issue appears.



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

Increase priority, will be fixed this weekend and in the next bugifx release

Comment by Benjamin Eberlei [ 30/Mar/12 ]

Are you using Postgresql Schema? Can you provide some information about your database tables? I need some more information to try reproducing this.

Comment by Nikolai Spassoff [ 03/May/12 ]

I'm experiencing the same issue.
I looked at the mentioned commit and found out that the SQL query in getSchemaNames() does not return any namespaces.
After some research I came with the following query to list all non-system namespaces in Postgres:

SELECT nspname as schema_name FROM pg_namespace WHERE nspname !~ '^pg_.*' and nspname != 'information_schema'

This fixed the issue for me and the schema-tool works again.

Comment by Benjamin Eberlei [ 05/May/12 ]

Fixed, but couldn't verify as the previous statement worked for me.





[DBAL-812] SchemaTool ignores multi-columns (composite) indexes when creating a foreign key Created: 13/Feb/14  Updated: 15/Feb/14

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

Type: Improvement Priority: Minor
Reporter: Peter Huynh Assignee: Steve Müller
Resolution: Unresolved Votes: 0
Labels: schematool
Environment:

MySQL



 Description   

When using the schema tool to generate the differences between the db and the entities, I notice the following:

ALTER TABLE sales ADD CONSTRAINT FK_36D222EF603EE73 FOREIGN KEY (vid) REFERENCES vendor (id);
CREATE INDEX IDX_36D222EF603EE73 ON sales (vid);

Normally, it doesn't bother me, however I have had an existing composite index consists of (vid, submit). This leads to the redundant index IDX_36D222EF603EE73 and therefore forcing unnecessary overheads.

It would be nice to have a mean to disable this from happening.

The code in question can be found at https://github.com/doctrine/dbal/blob/594e326bd58d1d7af578f0dc3143655b9d119d45/lib/Doctrine/DBAL/Schema/Table.php#L543.

A helpful member from #doctrine IRC also pointed out that it does not check the unique constraints also.

Regards,



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

Just a hint on this: looks like the current logic just checks hashed indexes, ignoring the "uniq" prefixed indexes to avoid duplicates.

Comment by Steve Müller [ 15/Feb/14 ]

Peter Huynh I get the point here. However after having a quick look into this it seems this behaviour exists for a good reason. See here: https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Schema/Index.php#L191-L195
The question is how could this reasonable extended to fulfil the needs you explained. I am not entirely sure about this and this peace of code is rather sensitive and critical. I don't want to rush any assumptions here.

Comment by Peter Huynh [ 15/Feb/14 ]

Hi Steve,

I fully understand your reservation.

Thanks for looking into things.

Peter





[DBAL-809] Decimal type: not convert to double variable type Created: 09/Feb/14  Updated: 09/Feb/14  Resolved: 09/Feb/14

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

Type: Bug Priority: Major
Reporter: Vitaliy Zhuk Assignee: Benjamin Eberlei
Resolution: Can't Fix Votes: 0
Labels: None


 Description   

Hi.

The doctrine DBAL type "decimal" not convert value to "double" variable type in PHP. And if use events for control changes set, we have a changes for field.

For example:

/** Entity class **/
/** @ORM\Column(name="field", type="decimal")
private $field;

/** Create entity **/
$entity = new MyEntity();
$entity->setField(1);
$em->persist($entity);
$em->flush($entity);

/** Load entity **/
$entity = $em->field('MyEntity', 1);
var_dump($entity->getField()); // Then we have a string type
$entity->setField(1); // Set a integer type

Listener (onFlush):

$em = $event->getEntityManager();
$uow = $em->getUnitOfWork();

$entity = $event->getEntity();
$changes = $uow->getEntityChangeSet($entity);

var_dump($changes); // Changes exists, because variable type not equals

https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Types/DecimalType.php#L52



 Comments   
Comment by Vitaliy Zhuk [ 09/Feb/14 ]

Sorry, i not seen the attention section in docs: http://docs.doctrine-project.org/projects/doctrine-dbal/en/latest/reference/types.html#decimal





[DBAL-761] Driver\ResultStatement::fetchAll() returns empty array on a seemingly valid Driver\PDOStatement object Created: 03/Jan/14  Updated: 08/Jan/14

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

Type: Improvement Priority: Minor
Reporter: Dennis Matveyev Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: mysql, orm, query, schematool
Environment:

Windows 7 64 bit, Zend Server/Studio, PHP 5.4.16,
Server: Apache/2.2.22 (Win32) mod_ssl/2.2.22 OpenSSL/0.9.8x



 Description   

I came across a weird issue, where when running:

vendor/bin/doctrine-module orm:schema-tool:update

I would get:

[Doctrine\DBAL\Schema\SchemaException]
There is no column with name 'resource_id' on table 'role_resource'.

But I did have a column with the above name in the above table, so that was a weird message for me. So I traced it all the way to this line of code:

https://github.com/doctrine/dbal/blob/2.4/lib/Doctrine/DBAL/Connection.php#L630

If I remove "->fetchAll()" from that line, I get this object:

object(Doctrine\DBAL\Driver\PDOStatement)#531 (1) {
["queryString"]=> string(332) "SELECT COLUMN_NAME AS Field, COLUMN_TYPE AS Type, IS_NULLABLE AS `Null`, COLUMN_KEY AS `Key`, COLUMN_DEFAULT AS `Default`, EXTRA AS Extra, COLUMN_COMMENT AS Comment, CHARACTER_SET_NAME AS CharacterSet, COLLATION_NAME AS CollactionName FROM information_schema.COLUMNS WHERE TABLE_SCHEMA = 'loginauth' AND TABLE_NAME = 'role_resource'"
}

Which has a valid SQL query that runs fine and shows Field names on my local machine's MySQL prompt. But when I add ->fetchAll() back in that line of code, an empty array is returned, field names are not returned, and a SchemaException is generated. I found this odd and wanted to report it. Whether it is a bug or not, hopefully I can find the cause of this issue.

For loads more info, please see this: http://stackoverflow.com/questions/20907491/doctrine-2-there-is-no-column-with-name-columnname-on-table-table



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

Dennis Matveyev It seems you are using MySQL. Can you please tell which version you use?

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

Dennis Matveyev Please also provide whether you use mysqli or PDO_MYSQL.

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

Dennis Matveyev Sounds dumb, but also are you sure that the vendor/bin/doctrine-module orm:schema-tool:update uses the correct connection parameters and does not by error connect to another database server or something? Because otherwise everything looks good IMO.

Comment by Dennis Matveyev [ 07/Jan/14 ]

Yes, I am using:
Server version: 5.5.23-log MySQL Community Server (GPL)
mysql client Ver 14.14 Distrib 5.5.23, for Win32 (x86)

Doctrine connection string for 'driverClass' is 'Doctrine\DBAL\Driver\PDOMySql\Driver', so it is PDO_MYSQL.

I am connecting to the right database, but your last suggestion is what helped to uncover the issue. When connecting to the database with the very same user/pass, and running the command, here is what I saw:

mysql> select resource_id from role_resource;
ERROR 1142 (42000): SELECT command denied to user 'login'@'localhost' for table 'role_resource'

Running a GRANT command to allow SELECT for this user solved the problem.

To improve debugging of similar issues, I'd see if there is a way to propagate the error from MySQL server to ./doctrine-module,
or
improve the error message of SchemaException, to i.e. "There is no column with name 'action_id' on table 'role_action', or database permissions prevent table access."

Thanks!

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

Dennis Matveyev Thank you for reporting this and I'm glad I could help. I will mark this as improvement, though. You are right in that the root cause of the error should be propagated to the user instead.

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

Dennis Matveyev Okay I found the root cause of the problem. See what MySQL states about access to the information_schema table for retrieving metadata about a certain database:

Each MySQL user has the right to access these tables, but can see only the rows in the tables that correspond to objects for which the user has the proper access privileges. In some cases (for example, the ROUTINE_DEFINITION column in the INFORMATION_SCHEMA.ROUTINES table), users who have insufficient privileges will see NULL.

So it returns NULL instead of raising an error and this is why Doctrine is not able to propagate the proper exception in this case. I'm not sure if changing the exception message in the SchemaException class is the proper way of handling this. Also please note that this is not only about columns (where you got stuck at) but can occurr for almost every list*() action called in the SchemaManager I suppose. Furthermore this might be a MySQL specific issue, not sure about that.

The proper solution would be to throw an exception much earlier, to have a decent behaviour in such an edge case. I think we should throw an exception here: https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Schema/AbstractSchemaManager.php#L267 because a table cannot live without columns and indicates an error somewhere. But I would like to hear the opinion of Benjamin Eberlei on that issue.

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

I checked the SQL Server documentation and it seems they behave exactly the same: http://technet.microsoft.com/en-us/library/ms187113.aspx

In SQL Server 2005 and later, the visibility of metadata is limited to securables that a user either owns or on which the user has been granted some permission. For example, the following query returns a row if the user has been granted a permission such as SELECT or INSERT on the table myTable.

However, if the user does not have any permission on myTable, the query returns an empty result set.





[DBAL-122] Impossible to save data to image/binary/varbinary Created: 16/May/11  Updated: 07/Jan/14  Resolved: 06/Jan/14

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

Type: Bug Priority: Major
Reporter: Martin Weise Assignee: Steve Müller
Resolution: Can't Fix Votes: 0
Labels: None
Environment:

XAMP, MsSQL-Server 2008, PHP 5.3.x, MS pdo_sqlsrv_vc6_ts.dll


Issue Links:
Reference
relates to DBAL-711 [GH-450] [DBAL-122] Fix BLOB type map... Resolved
relates to DBAL-714 [GH-452] Introduce BinaryType Resolved

 Description   

When trying to insert a value into a Column with type 'image', 'binary' or 'varbinary' the SQLServer states that this is not possible.
When trying to insert into 'binary' or 'varbinary' the error message is:
=> Implicit conversion from nvarchar(max) datatype to varbinary(max) is not allowed.

When trying to insert into 'image' the error message is:
=> Operand collision: nvarchar(max) is incompatible with image.

Doctrine prepares the image/binary/varbinary column in the statements as nvarchar(max) which is wrong.

The cause of this error is that in the MsSQLPlatform::getVarcharTypeDeclarationSQLSnippet($length, $fixed),
or in the datatype mapping which is to 'text'.

The documentation for the MsSQLServer states following conversions (http://207.46.16.252/de-de/library/ms187928.aspx):

*char => binary/varbinary : Explicit conversion
nchar/nvarchar => image : IMPOSSIBLE

So the solution would be, either to leave the datatype blank or use the char/varchar datatype when saving into image/binary/varbinary, which would cause an extra datatype as those would collide with 'text' I guess.



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

I get the problem, but i don't understand the solutions

Can you explain a bit more?

1. how do i leave a datatype empty? and which one?
2. how do i use char/varchar when saving?

I think this is just a problem of unspecific descriptions

Comment by Martin Weise [ 22/Feb/12 ]

Hi Benjamin

Sorry, for this long delay.
I had a deeper inspection what happens when I persist data into a field of type varbinary(MAX) and I got this (using the SQL profiler):

declare @p1 int
set @p1=NULL
exec sp_prepexec @p1 output,
N'@P1 nvarchar(36),@P2 nvarchar(max),@P3 nvarchar(34)',
N'INSERT INTO mc_dokument_data (id, data, mc_dokument_id) VALUES (@P1, @P2, @P3)',
N'03DDAAD1-4BFA-416B-A0C0-9B8B7148F31C',
N'0x3c3f786d6c20766572736...',
N'mwe3bc2c0da6543d1f48d7c83e64f5c449'
select @p1

But it has to be ( removed '-quotes and @P2 changed to varbinary(MAX) ):

declare @p1 int
set @p1=NULL
exec sp_prepexec @p1 output,
N'@P1 nvarchar(36),@P2 varbinary(max),@P3 nvarchar(34)',
N'INSERT INTO mc_dokument_data (id, data, mc_dokument_id) VALUES (@P1, @P2, @P3)',
N'03DDAAD1-4BFA-416B-A0C0-9B8B7148F31C',
0x3c3f786d6c20766572736...,
N'mwe3bc2c0da6543d1f48d7c83e64f5c449'
select @p1

I am not really sure any more if this is caused from Doctrine or from the 'MS SQL-Server PHP-PDO-Driver 2.0.1' .
But I guess this comes from the driver.
If you can validate this, I will make a bug report to them.

The funny thing is if I do this via executeQuery it works...

$data = unpack("H*" , __some__data__);
$data = '0x'.$data[1];

$em->executeQuery(
    "INSERT INTO mc_dokument_data (id, mc_dokument_id, data)". 
   "VALUES('".$id."' , '" . $documentId . "', " . $data . " )"
);

Hopefully I could clarify my problem.

Regards
Martin Weise

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

Is this now a bug in Doctrine? Can you please confirm this? I was not able to reproduce this issue. The only thing I can see is that back then we did not have a BLOB type in Doctrine that supplies the correct binding type for prepared statements. I don't know HOW you actually inserted the data which lead to an error but I guess it was a binding type problem in the driver coming from a wrong Doctrine type mapping (text instead of blob).
BLOB type mapping for SQL Server platform was introduced in this commit: https://github.com/doctrine/dbal/commit/854a67da503a9fd5a21bece282e3e32581d24d75
What is STILL wrong is the image and binary mapping. I will fix the image and binary type mappings to blob.

Comment by Marco Pivetta [ 19/Dec/13 ]

Steve Müller is this solved with https://github.com/doctrine/dbal/commit/c727c032a876e703ab964848ebf0a1eefed32a9a ?

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

Marco PivettaI don't know really. I cannot reproduce this error and I have to less additional information to do so. Obviously there have been wrong type mappings for the binary database types which al resolved to TextType. I think we have to wait for Feedback from Martin Weisethen.

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

Martin Weise As you did not provide further feedback and we introduced dedicate binary/varbinary Doctrine types that also provide the correct param mapping types and fixed the image/blob type mappings, I consider this ticket as resolved. We also have a lot of tests covering this. If you still encounter this issue, feel free to reopen
Anyways, thanks for reporting this!

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

Lol okay funny thing. I got to reproduce this now but only with PDO_SQLSRV. This is definitely a bug in the driver. See here:
http://social.msdn.microsoft.com/Forums/sqlserver/en-US/5a755bdd-41e9-45cb-9166-c9da4475bb94/how-to-set-null-for-varbinarymax-using-bindvalue-using-pdosqlsrv?forum=sqldriverforphp

Benjamin Eberlei What to do? Mention it anywhere in the docs? I don't know if it is fixed in a newer version. I am using version 3.0.3421.0. The native driver does not have this problem.

Comment by Benjamin Eberlei [ 04/Jan/14 ]

Steve Müller There is a known problems sections in the docs, we should mention it there. And then also mention this problem to the SQL Server team I guess.

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

Benjamin Eberlei I am currently fixing the functional test suites for the SQL Server drivers and will add that to the docs. Also I will skip the BlobTests for pdo_sqlsrv then for now. I think (according to the link I provided) the SQL Server team is already aware of that. It seems they haven't released a new version for quite a long time. But I will see if I can ping them again on this.

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

btw: See: http://sqlsrvphp.codeplex.com/SourceControl/latest#pdo_sqlsrv/pdo_stmt.cpp and search for "// TODO: This will eventually be changed to SQLSRV_PHPTYPE_STREAM when output streaming is implemented.". Then you know why varbinary/lob binding does not work.

Comment by Martin Weise [ 06/Jan/14 ]

Hi @all

Sorry for the long delay, but the project I am working on, did not update Doctrine for a long time and I started with a the latest version on another project only a month ago. Therefore I could not provide any further feedback and due the fact, that there were some Xmas things going on...

Anyway, it seems that the reason for this 'bug' is found. Is there anything I can do to help you ?

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

Martin Weise There is nothing you can do about when using pdo_sqlsrv. We added a notice to the docs to stick with sqlsrv if possible instead and skipped the BLOB related tests in the test suite. See: https://github.com/doctrine/dbal/commit/637ef6a1826a6937a5ab4fc4c73b8ede46732a73

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

I will close this for now as we cannot fix this driver bug. This might be reopended as soon as Microsoft fixes the bug in a newer version and we maybe can handle it properly.

Comment by Martin Weise [ 07/Jan/14 ]

Ok... Thank you for your help. Hopefully MS will fix this...





[DBAL-394] Unsigned integers are not respected by the schema tool for assocations Created: 30/Nov/12  Updated: 02/Jan/14  Resolved: 01/May/13

Status: Resolved
Project: Doctrine DBAL
Component/s: Schema Managers
Affects Version/s: 2.3
Fix Version/s: 2.4

Type: Bug Priority: Minor
Reporter: Jonathan Ingram Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 1
Labels: None

Issue Links:
Reference
is referenced by DDC-2661 Options not respected for ID Fields i... Resolved

 Description   

Before commenting, I've done so much debugging and searching into this issue and if I missed something major, I apologise.

From what I understand, the ORM doesn't care about unsigned. That's fair enough. That leaves it to DBAL to handle it.

However, it's not possible to successfully use something like the following table without having the schema manager complain.

CREATE TABLE `account` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT COMMENT '(DC2Type:unsigned_integer)',
  `user_id` int(10) unsigned DEFAULT NULL COMMENT '(DC2Type:unsigned_integer)',
  PRIMARY KEY (`id`),
  KEY `IDX_7D3656A461220EA6` (`user_id`)
) ENGINE=InnoDB

In that code, I'm using a custom type "unsigned_integer" that extends the DBAL integer type with this:

    public function getSQLDeclaration(array $fieldDeclaration, AbstractPlatform $platform)
    {
        $fieldDeclaration['unsigned'] = true;

        return $platform->getIntegerTypeDeclarationSQL($fieldDeclaration);
    }

The reason for this is because the ORM won't map unsigned ints for me. Combined with this is an event listener for the class metadata. Something like this:

    /**
     * Maps additional metadata.
     *
     * Specifically, if there exist an unsigned integer field, attach the
     * "unsigned" option to it. This is required because the Doctrine ORM does
     * not do this and we are using "UNSIGNED INT"s in our MySQL columns.
     * Without this. the Doctrine Schema Tool will complain about column
     * differences.
     *
     * Note: there is no performance impact in doing this because the class
     * metadata should be cached after the first request.
     *
     * @param LoadClassMetadataEventArgs $eventArgs
     */
    public function loadClassMetadata(LoadClassMetadataEventArgs $eventArgs)
    {
        foreach ($eventArgs->getClassMetadata()->fieldMappings as &$mapping) {
            if (isset($mapping['type']) && UnsignedIntegerType::UNSIGNED_INTEGER === $mapping['type']) {
                if (!isset($mapping['options'])) {
                    $mapping['options'] = array();
                }

                $mapping['options']['unsigned'] = true;
            }
        }
    }

Now, in the example table above, the schema tool will honour the "id" column, however it won't honour the association join column no matter what I do. My attempts include adding an event listener for class meta data as above (basically tricking the ORM) and also adding an event listener for the schema events.

The other day on GitHub there was a commit (https://github.com/doctrine/doctrine2/commit/a27be2fab61b1cfde4d2ecbc729a4a68816fca76) to help with this, but it's still not all working.

Also, comments and issues on the Jira tracker have said how there's legacy code related to "unsigned" and "default", but I can't tell what's legacy and what's allowed, especially when there's a commit like that one above.

By the way, I have found that the simple unsigned field mapping works. E.g.:

    fields:
        counter:
            type: integer
            column: counter
            options:
                unsigned: true

If it helps at all, here's the YAML mapping file for the above table/entity:

Account:
    type: entity
    table: account
    id:
        id:
            type: unsigned_integer
            generator:
                strategy: AUTO
    manyToOne:
        creator:
            targetEntity: User
            joinColumn:
                name: user_id
                referencedColumnName: id # Note: user table id is also unsigned_integer

Is it possible to 1) fix this or 2) let me know if I'm just doing something wrong?

Note: as I said above, I know that Doctrine DBAL and ORM does not care so much for unsigned ints because of portability, etc. but it seems that because of that commit above (24 days ago), there's a half-implememented/legacy solution going on here.

Cheers,
Jon



 Comments   
Comment by Benjamin Eberlei [ 01/May/13 ]

This was fixed in 657a54da

Comment by Gaetan Rousseau [ 03/May/13 ]

This was not fixed. We can use the option "unsigned" for the fields but not the id.

If someone has a solution or if you can fix this, that would be really cool !

Comment by Gaetan Rousseau [ 03/May/13 ]

After some research with a co-worker we've found a solution to our little problem.

To fix this you just have to add these lines in the YamlDriver (Doctrine/ORM/Mapping/Driver/YamlDriver.php) in the function "loadMetadataForClass", line 265 in the 2.3.3 version of Doctrine ORM :

if (isset($idElement['options'])) {
   $mapping['options'] = $idElement['options'];
}

Just before the :

$metadata->mapField($mapping);

And that an example of schema :

Entities\Test:
  type: entity
  table: Test
  id:
    id:
      type: integer
      options:
        unsigned: true
      generator:
        strategy: AUTO
  fields:
    testField:
      type: smallint
      options:
        unsigned: true

With this, the id can be unsigned without using special type of column, and yes just with this little if
It has been tested in more complexes schemas and all is going well.

In fact, maybe it could be interesting to use the function "columnToArray" like it's used for the other fields.
In the two cases you must care about what you put in your "options" section.

Comment by Benjamin Eberlei [ 08/Sep/13 ]

Gaetan Rousseau i just now found this additional bug report here in the comments. I opened DDC-2661 for it and fixed it. Will be included in 2.4.1. Please don't report additional bugs in already closed issues in the future, because they can easily get lost.

Comment by Doctrine Bot [ 02/Jan/14 ]

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





[DBAL-590] Doctrine\DBAL\Schema\Column::visit Calls a Method That Doesn't Exist on Doctrine\DBAL\Scema\Visitor\Visitor Created: 27/Aug/13  Updated: 01/Jan/14  Resolved: 01/Jan/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Schema Managers
Affects Version/s: 2.4, 2.3.4
Fix Version/s: 2.5

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

$ php -v
PHP 5.4.15 (cli) (built: Aug 16 2013 15:38:16)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies
with Xdebug v2.2.1, Copyright (c) 2002-2012, by Derick Rethans

$ uname -a
Darwin chrispmg.local 11.4.2 Darwin Kernel Version 11.4.2: Thu Aug 23 16:25:48 PDT 2012; root:xnu-1699.32.7~1/RELEASE_X86_64 x86_64



 Description   

`Column::visit` tries to `Doctrine\DBAL\Schema\Visitor\Visitor::accept`

https://github.com/doctrine/dbal/blob/2.3/lib/Doctrine/DBAL/Schema/Visitor/Visitor.php#L42
https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Schema/Column.php#L471

It doesn't look like `Visitor` actually has an `accept` method.
https://github.com/doctrine/dbal/blob/2.3/lib/Doctrine/DBAL/Schema/Visitor/Visitor.php
https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Schema/Visitor/Visitor.php

The method needed seems to be `Visitor:: acceptColumn`, but `Column` itself doesn't seem to be aware of it's parent table in any way.



 Comments   
Comment by Benjamin Eberlei [ 01/Jan/14 ]

Removed the method, the Table#visit() method is responsible for this.





[DBAL-293] mysql platform can not choose text type column Created: 20/Jun/12  Updated: 30/Dec/13  Resolved: 30/Dec/13

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

Type: Bug Priority: Minor
Reporter: Kiichi Kajiura Assignee: Benjamin Eberlei
Resolution: Cannot Reproduce Votes: 0
Labels: None


 Description   

getVarcharMaxLength() in DBAL/Platforms/MySqlPlatform.php returns 65535;
So, it never choose "text", choose "mediumtext".



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

How do you call the schema/platform code?

The code is correct, i think you are using it wrong.

Comment by Kiichi Kajiura [ 19/Jul/12 ]

I don't use it directly.
I use it in my entity class file with annotations.
e.g.
@Mapping\Column(type="text")
@Mapping\Column(type="text", length=65535)

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

Kiichi Kajiura TextType columns generate their SQL through AbstractPlatform::getClobTypeDeclarationSQL().
See: https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Types/TextType.php#L36

The implementation of this method in MySqlPlatform DOES evaluate the length option of a column and switches to the appropriate type on the fly.
See: https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Platforms/MySqlPlatform.php#L274-L293

So the implementation in DBAL is correct. AFAIK the column mapping information from ORM are also passed correctly to DBAL. I cannot reproduce this error. Can you please try it again with the current master branches of ORM and DBAL and see if the problem still exists? Otherwise I would like to close this ticket. Thank you.

Comment by Benjamin Eberlei [ 30/Dec/13 ]

This is not an issue, the code is clear about usage with "text" and length and not related to varchar max length.





[DBAL-558] Incorrect extracting of placeholder positions from statement Created: 15/Jul/13  Updated: 29/Dec/13  Resolved: 29/Dec/13

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: 2.3
Fix Version/s: 2.5, 2.4.2

Type: Bug Priority: Major
Reporter: Yevhen Shyshkin Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: None
Environment:

Linux Ubuntu 12.04 x64
PHP 5.3.10-1ubuntu3.6 with Suhosin-Patch
PostgreSQL 9.1.9



 Description   

I'm trying to execute statement:

SELECT Count(*)
FROM   (SELECT DISTINCT o6_.id                          AS id0,
                        COALESCE(t3_.content, o2_.name) AS name1,
                        o7_.postal_code                 AS postal_code2,
                        CASE
                          WHEN o7_.state_text IS NOT NULL THEN o7_.state_text
                          ELSE COALESCE(t5_.content, o4_.name)
                        END
                        || ''                           AS sclr3,
                        CASE
                          WHEN o6_.id IN ( ? )
                               AND o6_.id NOT IN ( ? ) THEN true
                          ELSE false
                        END                             AS sclr4
        FROM   orocrm_contact o6_
               LEFT JOIN orocrm_contact_value o8_
                      ON o6_.id = o8_.entity_id
               LEFT JOIN oro_flexibleentity_attribute o0_
                      ON o8_.attribute_id = o0_.id
               LEFT JOIN orocrm_contact_value_option o10_
                      ON o8_.id = o10_.value_id
               LEFT JOIN oro_flexibleentity_attribute_option o9_
                      ON o9_.id = o10_.option_id
               LEFT JOIN oro_flexibleentity_attribute_option_value o11_
                      ON o9_.id = o11_.option_id
               LEFT JOIN orocrm_contact_address o7_
                      ON o6_.id = o7_.owner_id
                         AND ( o7_.is_primary = true )
               LEFT JOIN orocrm_contact_to_contact_group o13_
                      ON o6_.id = o13_.contact_id
               LEFT JOIN orocrm_contact_group o12_
                      ON o12_.id = o13_.contact_group_id
               LEFT JOIN oro_dictionary_country o2_
                      ON o7_.country_code = o2_.iso2_code
               LEFT JOIN oro_dictionary_region o4_
                      ON o7_.region_code = o4_.combined_code
               LEFT JOIN oro_flexibleentity_attribute_translation t1_
                      ON t1_.locale = 'ru'
                         AND t1_.field = 'label'
                         AND t1_.object_class =
                             'Oro\Bundle\FlexibleEntityBundle\Entity\Attribute'
                         AND t1_.foreign_key = o0_.id
               LEFT JOIN oro_dictionary_country_translation t3_
                      ON t3_.locale = 'ru'
                         AND t3_.field = 'name'
                         AND t3_.object_class =
                             'Oro\Bundle\AddressBundle\Entity\Country'
                         AND t3_.foreign_key = o2_.iso2_code
               LEFT JOIN oro_dictionary_region_translation t5_
                      ON t5_.locale = 'ru'
                         AND t5_.field = 'name'
                         AND t5_.object_class =
                             'Oro\Bundle\AddressBundle\Entity\Region'
                         AND t5_.foreign_key = o4_.combined_code
        WHERE  ( CASE
                   WHEN o6_.id IN ( ? )
                        AND o6_.id NOT IN ( ? ) THEN true
                   ELSE false
                 END <> false )
               AND CASE
                     WHEN o7_.state_text IS NOT NULL THEN o7_.state_text
                     ELSE COALESCE(t5_.content, o4_.name)
                   END
                   || '' LIKE ?) AS e  

When this statement passes to Doctrine\DBAL\SQLParserUtils::getPlaceholderPositions, it extracts only three placeholder positions instead of five.

As a result, Doctrine can't map parameters and types properly, so SQL request fails.

It looks like this unexpected behavior appeared because of regular expression in SQLParserUtils::getUnquotedStatementFragments, that incorrectly extracts unquoted statements.



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

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

Comment by Doctrine Bot [ 29/Dec/13 ]

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





[DBAL-58] Schema tool does not see difference between onDelete="NO ACTION" and onDelete="RESTRICT" Created: 11/Aug/10  Updated: 28/Dec/13  Resolved: 28/Dec/13

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

Type: Improvement Priority: Major
Reporter: Jan Obrátil Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 1
Labels: None

Attachments: File Example.php    

 Description   

If database has ON DELETE CASCADE, schema tool detects change to NO ACTION and RESCRICT.
If database has ON DELETE RESCRICT, schema tool detects change only in case of CASCADE.
If database has ON DELETE NO ACTION, schema tool detect change only in case of CASCADE.

Detecting of changes is done by:
doctrine orm:schema-tool update --dump-sql
and
doctrine orm:validate-schema



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

which database version do yo uuse? can you paste an example schema?

Comment by Jan Obrátil [ 11/Aug/10 ]

This is example script with 2 testing entities.

Comment by Jan Obrátil [ 11/Aug/10 ]

I have attached script with two entities.

I have this database version:
$ mysql --version
mysql Ver 14.14 Distrib 5.1.41, for debian-linux-gnu (i486) using readline 6.1

Check line 44. There is CASCADE.
Updating schema by: $ doctrine orm:schema-tool:update

Change CASCADE to NO ACTION
$ doctrine orm:schema-tool:update --dump-sql
ALTER TABLE ArticleItem DROP FOREIGN KEY ArticleItem_ibfk_1;
ALTER TABLE ArticleItem ADD FOREIGN KEY (articleGroupId) REFERENCES ArticleGroup(id) ON DELETE NO ACTION

everything ok, so: $ doctrine orm:schema-tool:update

Change NO ACTION to RESTRICT
$ doctrine orm:schema-tool:update --dump-sql
// no output!!

Change RESTRICT to CASCADE
$ doctrine orm:schema-tool:update --dump-sql
ALTER TABLE ArticleItem DROP FOREIGN KEY ArticleItem_ibfk_1;
ALTER TABLE ArticleItem ADD FOREIGN KEY (articleGroupId) REFERENCES ArticleGroup(id) ON DELETE CASCADE

everything ok, so: $ doctrine orm:schema-tool:update

Change CASCADE to RESTRICT
$ doctrine orm:schema-tool:update --dump-sql
ALTER TABLE ArticleItem DROP FOREIGN KEY ArticleItem_ibfk_1;
ALTER TABLE ArticleItem ADD FOREIGN KEY (articleGroupId) REFERENCES ArticleGroup(id) ON DELETE RESTRICT

everything ok, do: $ doctrine orm:schema-tool:update

Change RESTRICT to NO ACTION
$ doctrine orm:schema-tool:update --dump-sql
// no output!!

So there is no way to update database schema from RESTRICT to NO ACTION and reverse!

Comment by Benjamin Eberlei [ 31/Oct/10 ]

Hm you are right, however for MySQL NO ACTION is the same as RESTRICT as stated by http://dev.mysql.com/doc/refman/5.1/en/innodb-foreign-key-constraints.html

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

Jan Obrátil As there internally is no difference between NO ACTION AND RESTRICT in MySQL I am closing this now. Doctrine generates the correct statements here when necessary.





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

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

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


 Description   

Move Schema related Creation code from AbstractPlatform to AbstractSchemaManager



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

Scheduled for Beta4

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

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

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

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





[DBAL-109] Doctrine/DBAL/Platforms/MySqlPlatform.php is missing test coverage around _getCreateTableSQL method Created: 12/Apr/11  Updated: 28/Dec/13  Resolved: 28/Dec/13

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

Type: Improvement Priority: Major
Reporter: Wil Moore III Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None
Environment:

2.1.0-DEV



 Description   

In "Doctrine/DBAL/Platforms/MySqlPlatform.php", the following methods are public: getShowDatabasesSQL, getCreateDatabaseSQL, getDropDatabaseSQL, getDropTableSQL (easy to test); however, the "_getCreateTableSQL" method is not public.

Is there a specific reason for this difference?

As a result of this method not being tested, there is a "quote" method being called which doesn't exist.

See: https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Platforms/MySqlPlatform.php#L410

The only way at this time to test for this case is to get an error when doing: $table->addOption('comment', '...');

I would suggest making the protected method public so it can be tested. I also suggest moving the options parsing out of _getCreateTableSQL into a helper method...this method seems a bit overloaded.

If agreed, I'm happy to take care of the cleanup. Just wanted to get some feedback on the ideas first.



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

This is an improvement

Comment by Steve Müller [ 24/Jun/13 ]

Is this issue still an issue? I neither see a "quote" method nor a "$table->addOption()" here...

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

Undefined method call fixed in commit: https://github.com/doctrine/dbal/commit/79e04e98895648e2a72075377dac13a3e7c7fd53





Length of a string column cannot exceed 255 (DBAL-62)

[DBAL-69] Varchar definition should automatically switch to CLOB for sizes larger than max varchar length. Created: 27/Nov/10  Updated: 23/Dec/13  Resolved: 23/Dec/13

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

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


 Description   

In the future we would probably allow arbitrary large sizes here and switch to a CLOB definition automatically if the specifed string length is larger than max length.



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

Fixed in commit: https://github.com/doctrine/dbal/commit/e57e92e1c0ee7e7949c5e82236a5bb96973ab044





[DBAL-139] Oracle's sequences with NOCACHE Created: 29/Jul/11  Updated: 22/Dec/13  Resolved: 22/Dec/13

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: 2.0.6
Fix Version/s: 2.5

Type: Improvement Priority: Major
Reporter: Augusto Ximenes de Souza Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 1
Labels: None


 Description   

Hi community,

Today I tried to generate Oracle's sequences with "NOCACHE", but I checked that method "getCreateSequenceSQL" don't accept. Can we improvement this method to allow? Below an example of the sintaxe:

CREATE SEQUENCE seq_test START WITH 1 INCREMENT BY 1 NOCACHE



 Comments   
Comment by Ivan Andric [ 22/Sep/12 ]

Hi,

If cache value is specified then syntax should contain CACHE keyword that follows the value and if value is not specified then it should go without CACHE keyword.
In this case sequence will be created with CACHE value 20 by default.
Min cache value is 2 and for determine max value we should have sequence max value defined which is by default 10^27 for an ascending sequence and -1 for a descending sequence.
Now the max cache value is calculated by the formula (CEIL (MAXVALUE - MINVALUE)) / ABS (INCREMENT).

My Idea is to add cache attribute to Sequence object and then under the previous story, set cache to given value if value is greater than 1 and less than calculation by the given formula.

For nocache,
I would use value of 0 so we will have values in domain (0,1<x<=(CEIL (MAXVALUE - MINVALUE)) / ABS (INCREMENT)).

Some public function will return NOCACHE or CACHE n and that function could be called in getCreateSequenceSQL method from Sequence input parameter.

Anyone have a better idea or I can code this and request pull from my fork?

Comment by Ramon Henrique Ornelas [ 08/Nov/12 ]

Duplicate issue http://www.doctrine-project.org/jira/browse/DBAL-348

Greetings
Ramon Ornelas





[DBAL-544] Where's the Query::HYDRATE_BOTH constant? Created: 12/Jun/13  Updated: 22/Dec/13  Resolved: 22/Dec/13

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

Type: Bug Priority: Minor
Reporter: Julio Montoya Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: Query::HYDRATE_BOTH
Environment:

Doctrine 2.3.4 DBAL + ORM, using Silex



 Description   

In the documentation of the the ResultStatement::fetch() function says that we should use the Query::HYDRATE_* constants but that constant does not exist at least not in 2.3.4.

Should I just use PDO::FETCH_BOTH? But if I change the driver to sqlite or whatever is it going to work well?



 Comments   
Comment by Marco Pivetta [ 12/Jun/13 ]

Query constants are defined in AbstractQuery (superclass of the Query class) - see https://github.com/doctrine/doctrine2/blob/2.3.4/lib/Doctrine/ORM/AbstractQuery.php#L45-L60

Comment by Julio Montoya [ 12/Jun/13 ]

Hello Marco! Thanks for your fast answer!
Some comments: The constant HYDRATE_BOTH doesn't exist, at least not with that name. Documentation should be updated too.
Another thing I'm obliged to use ORM to call a constant in DBAL? Not a problem for me because I need both

Comment by Marco Pivetta [ 12/Jun/13 ]

Sorry, confused this one as an ORM issue.

Comment by Marco Pivetta [ 12/Jun/13 ]

Checked briefly - you should indeed use the `PDO::FETCH_*` constants.

Can you link the document that contains the imprecision?

Comment by Julio Montoya [ 12/Jun/13 ]

This is the documentation in the fetch(), fetchAll() functions in DBAL:

https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Driver/ResultStatement.php#L61

For example, if I want to fetch an Object what should I use 1. or 2. ? I don't know if this have some implications in other drivers.

1. $statement->fetch(\Doctrine\ORM\Query::HYDRATE_OBJECT);
2. $statement->fetch(PDO::FETCH_OBJ);

An update to the documentation will be fine too:

http://docs.doctrine-project.org/projects/doctrine-dbal/en/latest/reference/data-retrieval-and-manipulation.html#using-prepared-statements

it should be:

fetch($fetchMode)

instead of

fetch($fetchStyle)

with a list of options (constants) ...

Comment by Julio Montoya [ 13/Jun/13 ]

Working in a PR but first we need to define those constants ...

https://github.com/jmontoyaa/dbal/commit/d3a44589cdef6c146592eee2b2bd9f8907dadd1f

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

I guess this is a Doctrine 1 legacy problem. I was confused by the methods' documentation today, too. I think the documentation was copied from Doctrine 1 code and never updated. You should definitely use PDO_FETCH* constants for this as the drivers rely on this. I will PR a documentation update these days...

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

Documentation fixed in commit: https://github.com/doctrine/dbal/commit/7fc6b420a296504c56859f67ed1dc16a9a3bbdfe





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

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

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


 Description   

The API could be improved in the next major release:

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

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

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



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

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

Comment by Till [ 12/Aug/12 ]

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

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

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





[DBAL-59] Add support for PDO_CUBRID driver when stable Created: 09/Nov/10  Updated: 17/Dec/13  Resolved: 17/Dec/13

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

Type: New Feature Priority: Minor
Reporter: Benjamin Eberlei Assignee: Steve Müller
Resolution: Won't Fix Votes: 3
Labels: None


 Description   

CUBRID is a relational database focused on high performance web-apps. If the PDO_CUBRID http://pecl.php.net/package/PDO_CUBRID gets stable or betaish anytime we should think about support it.



 Comments   
Comment by Esen Sagynov [ 22/Aug/11 ]

Hello, I was recently looking if Doctrene supports CUBRID and found this issue. CUBRID PDO Driver is production-ready now, being used in Yii PHP Framework, for instance.

I am CUBRID Project Manager and would like to know if you plan to elevate this issue up so that we could use Doctrene, too. We also plan to include Doctrene into CUBRID Projects site after it gets official support.

If you need any assistance, let me know. I will be glad to assist you.

Comment by Robert Weclawski [ 30/Nov/13 ]

hello,
any news here ?


Regards,
Robert

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

I will start development on this now. Hoping to get the implementation finished until the end of the year.

Unfortunately there does not seem to be a launchpad repository for Ubuntu Saucy, therefore I will have to compile the package first.

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

We reevaulated this issue and came to the conclusion that we won't include this in the core. We don't want to maintain the driver on our side for just a few users actually using it in the end. It's hard work keeping all the driver implementation in sync and we don't want to afford the effort for such a minority of users. If you really need this implementation, you have to do it on your own I'm afraid.





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

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

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

Symfony 2.1, SQL Server 2008, driver: pdo_sqlsrv



 Description   

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

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

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

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



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

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

Comment by Flip [ 27/Nov/13 ]

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

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

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

Comment by Benjamin Eberlei [ 13/Dec/13 ]

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

Comment by Flip [ 13/Dec/13 ]

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

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

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

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

Thx guys for the input on this issue.

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

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





[DBAL-367] Reverse engnering do not work with Oracle DB Created: 18/Oct/12  Updated: 21/Nov/13  Resolved: 21/Nov/13

Status: Resolved
Project: Doctrine DBAL
Component/s: Drivers, Schema Managers
Affects Version/s: 2.3
Fix Version/s: 2.5

Type: Bug Priority: Major
Reporter: Zelenin Alexandr Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: Cli, oracle, schematool
Environment:

PHP 5.3.3-1ubuntu9.10 with Suhosin-Patch (cli) (built: Feb 11 2012 06:21:15)
oci8-1.4.7 as PHP extension builded from pecl repository with instantclient-basic-linux.x64-11.2.0.3.0.zip and instantclient-sdk-linux.x64-11.2.0.3.0.zip
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production



 Description   
$ doctrine orm:convert-mapping --filter="ms$ions" xml .

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

cli-config.php:

use Doctrine\Common\Annotations\AnnotationReader;
use Doctrine\Common\Annotations\AnnotationRegistry;

require_once 'Doctrine/Common/ClassLoader.php';

define('APPLICATION_ENV', "development");
error_reporting(E_ALL);

$classLoader = new \Doctrine\Common\ClassLoader('Doctrine');
$classLoader->register();

$config = new \Doctrine\ORM\Configuration();
$config->setProxyDir(__DIR__);
$config->setProxyNamespace('Proxies');

$config->setAutoGenerateProxyClasses((APPLICATION_ENV == "development"));

AnnotationRegistry::registerFile("Doctrine/ORM/Mapping/Driver/DoctrineAnnotations.php");
$reader = new AnnotationReader();
$driverImpl = new \Doctrine\ORM\Mapping\Driver\AnnotationDriver($reader, array(__DIR__ . "/../php/ru/niifhm/bioinformatics/biodb/model"));
$config->setMetadataDriverImpl($driverImpl);

if (APPLICATION_ENV == "development") {
    $cache = new \Doctrine\Common\Cache\ArrayCache();
} else {
    $cache = new \Doctrine\Common\Cache\ApcCache();
}

$config->setMetadataCacheImpl($cache);
$config->setQueryCacheImpl($cache);

$connectionOptions = array(
    'driver'   => 'oci8',
    'host'     => 'host.name',
    'dbname'   => 'db.name',
    'user'     => 'user.name',
    'password' => 'user.password'
);

$em = \Doctrine\ORM\EntityManager::create($connectionOptions, $config);
$platform = $em->getConnection()->getDatabasePlatform();
$platform->registerDoctrineTypeMapping('enum', 'string');

$em->getConfiguration()->setMetadataDriverImpl(
    new \Doctrine\ORM\Mapping\Driver\DatabaseDriver(
        $em->getConnection()->getSchemaManager()
    )
);

$helperSet = new \Symfony\Component\Console\Helper\HelperSet(array(
    'db' => new \Doctrine\DBAL\Tools\Console\Helper\ConnectionHelper($em->getConnection()),
    'em' => new \Doctrine\ORM\Tools\Console\Helper\EntityManagerHelper($em)
));


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

Formatting

Comment by Steve Müller [ 07/Nov/13 ]

Should be fixed with following PR:

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

Comment by Doctrine Bot [ 13/Nov/13 ]

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





[DBAL-318] getSQLDeclaration Created: 12/Aug/12  Updated: 21/Nov/13  Resolved: 21/Nov/13

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

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


 Description   

https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Types/Type.php#L119-L125

Should define a @return type. Otherwise you have to step through other types to figure this out.



 Comments   
Comment by Christophe Coevoet [ 19/Aug/12 ]

Already fixed in master





[DBAL-200] Connection::update() Created: 10/Jan/12  Updated: 21/Nov/13  Resolved: 21/Nov/13

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

Type: Documentation Priority: Trivial
Reporter: Jonas Liljestrand Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: documentation


 Description   

missing @param array $data in docblock



 Comments   
Comment by Padraig O'Sullivan [ 11/Dec/12 ]

Resolved by pull request 236:

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





[DBAL-100] Add Drizzle Support Created: 16/Mar/11  Updated: 21/Nov/13  Resolved: 21/Nov/13

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

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


 Description   

Drizzle is out, we should add support for the Dialect.

http://docs.drizzle.org/mysql_differences.html



 Comments   
Comment by Andreas Streichardt [ 22/Dec/11 ]

i have created some hackish fork and the whole testsuite is working already:

https://github.com/m0ppers/dbal

Still WIP but may be a start. I think the C extension is not really ready yet either. When i find time i will most likely have a look at it.

Comment by Benjamin Eberlei [ 22/Dec/11 ]

Can you branch it into something, like git checkout -bDrizzle then push it to your repo and open a Pull Request? Thats way easier to review and discuss.

Comment by Steve Müller [ 24/Jun/13 ]

Isn't this already implemented?

Comment by Kim Hemsø [ 02/Aug/13 ]

Yes it is, long time ago. Well.. difference is that Andreas here is using the now (dead?) native drizzle ext. Where dbal is using pdo for mysql.





[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-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-153] Github-PR-48 by phekmat: Added a regression test case for recently fixed PostgreSQLSchemaManager bug Created: 21/Aug/11  Updated: 20/Nov/13  Resolved: 20/Nov/13

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

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

Message:

Regression test for the following change: https://github.com/doctrine/dbal/commit/2434d95aab231273eea8fb555155e9e9c195bcc9



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

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

Comment by Benjamin Eberlei [ 24/Mar/12 ]

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

Comment by Benjamin Eberlei [ 24/Mar/12 ]

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





[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-81] Add support for auto-commit = NO accross databases Created: 02/Jan/11  Updated: 12/Nov/13  Resolved: 12/Nov/13

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

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


 Description   

Currently all databases are running in AUTO-COMMIT = Yes Mode. This means that you have to explicitly open a transaction to be able to use transactional features.

There should be support to run in auto-commit = no mode, which means after connect and after each commit a new transaction is opened automatically.



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

PR:

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

Comment by Doctrine Bot [ 12/Nov/13 ]

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





[DBAL-615] Escape platform identifiers in ALTER queries Created: 26/Sep/13  Updated: 09/Oct/13  Resolved: 26/Sep/13

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: 2.4, 2.4.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Arthur Bodera Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None


 Description   

PR302 introduced platform quoting for manipulation of PK, FK and indexes. Alter queries are left unquoted, which means that ALTER with table names that happen to be reserved platform keywords, will fail.

For example:

ALTER TABLE order DROP FOREIGN KEY FK_F5299398D5289B7F;
ALTER TABLE set DROP FOREIGN KEY FK_E61425DC1BF22D93;
ALTER TABLE storage ADD CONSTRAINT FK_547A1B3487068541 FOREIGN KEY (`addressId`) REFERENCES `address` (`id`);


 Comments   
Comment by Arthur Bodera [ 26/Sep/13 ]

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

Comment by Doctrine Bot [ 26/Sep/13 ]

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

Comment by Arthur Bodera [ 09/Oct/13 ]

It's not invalid.

Discussion here: https://github.com/doctrine/dbal/pull/379





[DBAL-83] BigInt Type is returning string instead of integer Created: 28/Jan/11  Updated: 08/Sep/13  Resolved: 14/May/11

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

Type: Bug Priority: Major
Reporter: Miloslav "adrive" Kmet Assignee: Benjamin Eberlei
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

I ran all tests with PostgreSQL and I got an error:

1) Doctrine\Tests\DBAL\Functional\TypeConversionTest::testIdempotentDataConversion with data set #3 ('bigint', 12345678, 'string')
The expected type from the conversion to and back from the database should be string
Failed asserting that <integer:12345678> is of type "string".

/usr/share/php/Doctrine2/dbal/tests/Doctrine/Tests/DBAL/Functional/TypeConversionTest.php:84

FAILURES!
Tests: 367, Assertions: 745, Failures: 1, Skipped: 8.

The BigInt Type is missing convertToPHPValue() method and returns string instead of int. I fixed this and also I fixed the test case for this. Patch will be availabe via github pull request.



 Comments   
Comment by Benjamin Eberlei [ 14/May/11 ]

Bigints have to be strings for int overflow reasons. PostgreSQL seems to detect 64 vs 32bit systems and casts correctly, this is unfortunate for the tests, i have to come up with a workdaround for this

Comment by Giovanni Lovato [ 08/Sep/13 ]

This behavior can't be correct:

php > var_dump($object->id);
int(201308090001)
php > $em->persist($object);
php > var_dump($em->find(get_class($object), 201308090001)->id);
string("201308090001");

The type should be consistent no matter what, otherwise the idempotent requirement breaks.

Comment by Benjamin Eberlei [ 08/Sep/13 ]

Giovanni Lovato This was fixed, bigint identity generation will always work with strings.





[DBAL-116] Support Array type For Postgresql Created: 29/Apr/11  Updated: 05/Aug/13  Resolved: 30/Apr/11

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

Type: Improvement Priority: Minor
Reporter: Brice Maron Assignee: Benjamin Eberlei
Resolution: Won't Fix Votes: 0
Labels: None
Environment:

Postgresql >= 8.4



 Description   

Hi,

Since at least postgres 8.4 , pg support arrays...
it could be nice if doctrine could read them as a type instead of use a string for it.
Postgresql also offer a sort of hash array named hstore...

Thanks

http://www.postgresql.org/docs/8.4/static/arrays.html

http://www.postgresql.org/docs/8.4/static/hstore.html



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

This will not be implemented as it is implementation specific whereas Doctrine features need to be supported by all vendors.

You can already implement this with custom types though, i remember testing this some time ago.

Comment by Karsten Dambekalns [ 19/Oct/12 ]

Why is this not to be implemented? It can be used by the PostgreSQL driver without anything above it needing change - all platform drivers exist precisely to deal with implementation specifics… No?

Comment by Karsten Dambekalns [ 05/Aug/13 ]

Coming back to this and still wonder why it cannot be implemented. Could even be a solution / combined with DBAL-369

Comment by Benjamin Eberlei [ 05/Aug/13 ]

See https://github.com/easybiblabs/EasyBib_DoctrineTypes for an implementation of PostgreSQL Hstore. Arrays can be implemented the same way.





[DBAL-178] Unknown column type requested Created: 02/Nov/11  Updated: 05/Aug/13  Resolved: 26/Jun/12

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

Type: Improvement Priority: Minor
Reporter: Francois Mazerolle Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 1
Labels: None
Environment:

OSX ( Using Symfony2 )



 Description   

When I run doctrine:schema:create, doctrine throw the following exception:
[Doctrine\DBAL\DBALException]
Unknown column type requested.

( Note: their is 2 spaces between type and requested )

The problem with this error message is how much it's unspecific. Event with -v, I still have no clue about that type is wrong, and what file is concerned.
So basically, I have to manually look at all my mapping files, one by one.

Also note that doctrine:mapping:info return all OK.



 Comments   
Comment by Denny Swindle [ 21/Nov/11 ]

Ironically, this same issue has recently started happening for me as well. It just started randomly over the weekend. Same exact issue (with 2 spaces between type and requested). For me, it happens when using Doctrine\ORM\EntityManager->find() on a valid entity.

#0 /doctrine-2.1.2/Doctrine/DBAL/DBALException.php(81): Doctrine\DBAL\DBALException::unknownColumnType()
#1 /doctrine-2.1.2/Doctrine/DBAL/Types/Type.php(140): Doctrine\DBAL\DBALException::unknownColumnType()
#2 /doctrine-2.1.2/Doctrine/ORM/Internal/Hydration/SimpleObjectHydrator.php(84): Doctrine\DBAL\Types\Type::getType()
#3 /doctrine-2.1.2/Doctrine/ORM/Internal/Hydration/SimpleObjectHydrator.php(43): Doctrine\ORM\Internal\Hydration\SimpleObjectHydrator->_hydrateRow()
#4 /doctrine-2.1.2/Doctrine/ORM/Internal/Hydration/AbstractHydrator.php(99): Doctrine\ORM\Internal\Hydration\SimpleObjectHydrator->_hydrateAll()
#5 /doctrine-2.1.2/Doctrine/ORM/Persisters/BasicEntityPersister.php(581): Doctrine\ORM\Internal\Hydration\AbstractHydrator->hydrateAll()
#6 /doctrine-2.1.2/Doctrine/ORM/EntityRepository.php(130): Doctrine\ORM\Persisters\BasicEntityPersister->load()
#7 /doctrine-2.1.2/Doctrine/ORM/EntityManager.php(350): Doctrine\ORM\EntityRepository->find()

Comment by Gediminas Morkevicius [ 21/Jan/12 ]

hi, seems like doctrine does not clean cache fully.

in my case I'm using APC cache
run: in php *apc_clear_cache('user');*

it should work fine now

PS.:
running cache clearing commands, does not help.

doctrine:cache:clear-metadata Clears all metadata cache for a entity manager
doctrine:cache:clear-query Clears all query cache for a entity manager
doctrine:cache:clear-result Clears result cache for a entity manager

Comment by Francois Mazerolle [ 23/Jan/12 ]

Hi,

@gediminas : I don't have the error anymore so I can't test, but it's nice if there's a solution to fix it.

However, this error is problematic as it's anti-verbose.
There's is no indication of a cache problem in the error message. It try to point out to a field, and that field is not even displayed in the error.
I hope someone will be able to fix the error so that's it become a useful error, like by following some sort of guideline:

http://www.useit.com/alertbox/20010624.html

I don't want to troll or anything, but as I'Ve started using doctrine2 with symfony2, the MAJOR problem I've encountered what bad error message that was leaving me lost. Often I had -v, find the file where the error occurred, look at the code, understand by myself what's wrong and attempt to fix it. This is counter-productive and really show that the exception message doesn't follow most error message guide line. For sure, we're not end-users, but we're "programmer-user" that use the system, and this "title" come with a knowledge that is not the same as we could expect of a core-developer, for example.

I hope this message was constructive.

Comment by Benjamin Eberlei [ 26/Jun/12 ]

Improved this error message alot and also changed some regarding reverse engineering of custom types (where this error often occured):

You can now implement Type#getMappedDatabaseTypes(AbstractPlatform $platform); on your custom type and return a list of database types that this doctrine type maps to.

Comment by Almog Baku [ 05/Aug/13 ]

this bug is still happening to me.. but its works as excepted within `schema:create` and throw error on `schema:update` or `schema:drop`

I using doctrine with symfony





[DBAL-565] MySQL 5.6, Doctrine\DBAL\DBALException: Unknown database type bit requested. Created: 22/Jul/13  Updated: 22/Jul/13  Resolved: 22/Jul/13

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

Type: Bug Priority: Major
Reporter: Arthur Bodera Assignee: Benjamin Eberlei
Resolution: Won't Fix Votes: 0
Labels: None
Environment:

Mysql 5.6.12, MacOS, PHP 5.4.16.



 Description   

Given the following db table connected with an ORM entity:

CREATE TABLE `foo` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `bitField` bit(1) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Running something like orm:validate-schema will result in the following exception.

[Doctrine\DBAL\DBALException]
Unknown database type bit requested, Doctrine\DBAL\Platforms\MySqlPlatform may not support it.

BIT datatype is available since mysql 5.0.3 but D2 Mysql platform doesn't seem to understand it



 Comments   
Comment by Marco Pivetta [ 22/Jul/13 ]

Arthur Bodera the platforms only support base types (common to all platforms) out of the box. If you want additional types, you need to register them.

Comment by Arthur Bodera [ 22/Jul/13 ]

It seems that BIT(M) column represents packed bits and is not directly transferable to "boolean", nor to (unpacked) "binary" d2 types. This leaves this column type in an awkward position, where no d2 built-in type matches it perfectly. Mapping it to "boolean" limits its scope and could result in data loss. Mapping it to "binary" could result in unexpected behavior.

Right now, the only 2 valid solutions I see are:





[DBAL-57] Handling of Quoted Elements Created: 30/Oct/10  Updated: 24/Jun/13

Status: Open
Project: Doctrine DBAL
Component/s: Schema Managers
Affects Version/s: 2.0.0-BETA4
Fix Version/s: None

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

Issue Links:
Reference
is referenced by DDC-832 Not quoted class name when updating e... Resolved

 Description   

Handling of Quoted Table, Column (etc) names is not as good as it could be. Any input is currently accepted, however it is not processed further and used in conjunction with the platform.



 Comments   
Comment by Steve Müller [ 24/Jun/13 ]

May this be an issue fixed by https://github.com/doctrine/dbal/pull/302 ?





[DBAL-508] MySqlSchemaManager accessing undefined index tableColumn[comment] Created: 30/Apr/13  Updated: 09/May/13  Resolved: 09/May/13

Status: Resolved
Project: Doctrine DBAL
Component/s: Schema Managers
Affects Version/s: 2.3.3
Fix Version/s: 2.4

Type: Bug Priority: Trivial
Reporter: Martin Kuckert Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None
Environment:

Linux 3.2.0-24-generic-pae #39-Ubuntu,
mysql Ver 14.14 Distrib 5.5.31, for debian-linux-gnu (i686) using readline 6.2



 Description   

in the method Doctrine\DBAL\Schema\MySqlSchemaManager::_getPortableTableColumnDefinition the index "comment" in the array $tableColumn is accessed without ensuring that this index is set. This leads to an Undefined index: comment warning in E_ALL-environments.

This method is triggered e.g. by the Doctrine\ORM\Tools\SchemaTool getUpdateSchemaSql method.



 Comments   
Comment by Benjamin Eberlei [ 01/May/13 ]

Can't really explain this, the key has to be existant. This is only called with information from MysqlPlatform#getListTableColumnsSQL().

Comment by Martin Kuckert [ 02/May/13 ]

I've just found the issue. The main problem is the usage of 'DESCRIBE ' . $table; in the getListTableColumnsSQL, if there's no $database set. describe does not return the comment column, but 'show full columns from ' . $table; does.
At the basis of the missing $database value was my own DBAL\Driver implementation not properly returning the currently connected database. So $database was NULL and the alternate code path was executed, so resulting in no comment-property.

Seems like an uncovered code path instead of a bug in a real environment.

Comment by Benjamin Eberlei [ 09/May/13 ]

Special case fixed for 2.4





[DBAL-384] Missing TIMESTAMP support Created: 16/Nov/12  Updated: 27/Apr/13  Resolved: 27/Apr/13

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: 2.0, 2.1, 2.2, 2.3
Fix Version/s: 2.2.2

Type: Improvement Priority: Minor
Reporter: Harrie Bos Assignee: Benjamin Eberlei
Resolution: Won't Fix Votes: 0
Labels: None

Attachments: Text File timestamp.patch    

 Description   

Here's a fix to add support for a TIMESTAMP field in the database.



 Comments   
Comment by Florin Patan [ 18/Nov/12 ]

@Benjamin should I create a PR for this on GH?

Comment by Harrie Bos [ 18/Nov/12 ]

I think it should be fixed in one of the next releases

Comment by frank [ 26/Apr/13 ]

this aint working.. further more i used... http://www.doctrine-project.org/jira/secure/attachment/11350/timestamp.patch

which includes a bit more.. like the actual timestamp.php

but still getting error

Could not convert database value "0000000016E2BCF7" to Doctrine Type timestamp. Expected format: Y-m-d H:i:s

500 Internal Server Error - ConversionException

Comment by Benjamin Eberlei [ 27/Apr/13 ]

Please add this as a custom type to your own project if you need it, this is not going to be part of DBAL Core





[DBAL-487] DBAL's SqlitePlatform does not allow for fields of type 'integer unsigned'. Whether they exist already or not. Created: 05/Apr/13  Updated: 20/Apr/13  Resolved: 20/Apr/13

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: 2.3.3
Fix Version/s: 2.3.4

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


 Description   

I'm getting the following error when I'm merely requesting schemaManager->listTables() on an SQLite DB with several columns set to 'integer unsigned'.

PHP Fatal error: Uncaught exception 'Doctrine\DBAL\DBALException' with message 'Unknown database type integer unsigned requested, Doctrine\DBAL\Platforms\SqlitePlatform may not support it.' in /..snip../vendor/doctrine/dbal/lib/Doctrine/DBAL/Platforms/AbstractPlatform.php:321

$ sqlite3 --version
3.7.14.1



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

Fixed





[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-102] SQLSRV PDO doesn't support DateTime as a PHP Object Created: 19/Mar/11  Updated: 15/Mar/13  Resolved: 14/Sep/11

Status: Resolved
Project: Doctrine DBAL
Component/s: Drivers
Affects Version/s: 2.1
Fix Version/s: 2.1.3

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

Windows 7, Microsoft SQL Server 2008, PHP SqlSrv Driver 2.0, PHP 5.3.6



 Description   

I have created an entity with has a datetime column

Entity.php
    /**
     * @orm:Column(name="deleteAt", type="datetime")
     */
    protected $deletedAt;

    /**
     * Get DeletedAt
     * @return	\DateTime	
     */
    public function getDeletedAt() {
    	return $this->deletedAt;
    }
    
    /**
     * Set DeletedAt
     * @param	\DateTime		$deletedAt
     */
    public function setDeletedAt(\DateTime $deletedAt) {
        $this->deletedAt = $deletedAt;
    }

This should work, however I get this error when trying to set a "deleteAt" date

$this->setDeletedAt(new \DateTime());
SQLSTATE[22007]: [Microsoft][SQL Server Native Client 10.0][SQL Server]Conversion failed when converting date and/or time from character string.

This should work afaik.



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

Are yo using columns of type "datetime" or "datetime2" in MSSQL? The former is not supported.

Comment by Aaron DM [ 21/Mar/11 ]

I did not know datetime was not supported. I am using the column type "datetime"

Comment by Benjamin Eberlei [ 21/Mar/11 ]

In this case you have to add your own datetime type and change the timestamp format, or use the VarDateTime instead by calling "overrideType". Have a look at the Doctrine\DBAL\Types folder, escpecially the Type.php, DateTimeType.php and VarDateTimeType.php

Comment by Aaron DM [ 29/Mar/11 ]

I have now tried this with the column type "datetime2", which creates the following date format in the database
"2011-03-27 06:07:00.000000"

And I am still getting the same error
"SQLSTATE[22007]: [Microsoft][SQL Server Native Client 10.0][SQL Server]Conversion failed when converting date and/or time from character string."

P.S. this time I tried doing a select
WHERE deletedAt > (datetime)

Comment by Benjamin Eberlei [ 29/Mar/11 ]

Assigned to juokaz

Comment by Aaron DM [ 29/Mar/11 ]

When i ran profile, this is what I see

" AND (a0_.deleted_at <= @P3) ORDER BY a0_.deleted_at DESC','810678','Object','Object'"

Expliclitly converting the DateTiem to a string works

$query->setParameter("deletedAt", $deletedAt->format("Y-m-d H:i:s.u"));

Comment by Juozas Kaziukenas [ 29/Mar/11 ]

Can you give a full code which you use to query this (or the smallest allowing to replicate). I can't see how DateTime object gets passed as a 'Object' to the query, this is handled by DBAL type system, not by mssql platform, which only specifies the date and/or time format.

Comment by Benjamin Eberlei [ 30/Mar/11 ]

Does the error happen during a DQL or during flush (UPDATE/INSERT) ?

Comment by Aaron DM [ 30/Mar/11 ]

https://gist.github.com/6b2a8b53ece6e75abf20

The code there works (its not fully complete, but I tested the statements with the same Entity and etc and I am unable to successfully query the database).

Looks like it doesn't work even for a simple select. However if I do retrieve an entry, the getCreatedAt() does return a DateTime object correctly.

Comment by Guilherme Blanco [ 13/Sep/11 ]

Is this issue still valid with new implementation of ParameterTypeInferer in ORM?

It seems it solved this issue.

Comment by Guilherme Blanco [ 14/Sep/11 ]

Closing since no response was given.

Comment by Michał Banaś [ 15/Mar/13 ]

Why is it close ? After one day of waiting for response?
Problem is not solved. It exist on ether datetime and datetime2 TSQL types.
And it is easy to check if you have sqlserver databes.
PLease repoen this issue.

Comment by Marco Pivetta [ 15/Mar/13 ]

Michał Banaś this actually works with the current implementation of the schema tools. Consider implementing additional formats a custom DBAL type instead.





[DBAL-452] range is a reserved word in several platforms Created: 21/Feb/13  Updated: 15/Mar/13  Resolved: 14/Mar/13

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

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

Linux 64bit



 Description   

'range' is a reserved word for MySQL, Oracle, and on future reserved list for SQL Server as well so should really be added for escaping. Working on a new project using Doctrine accessing an external API which used it as a field and got an error when running orm:schema-tool:create on my entity with MySQL.



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

Added for MySQL and Oracle. Didn't find data on when its added to SQL Server.

Comment by Michael Cummings [ 15/Mar/13 ]

http://msdn.microsoft.com/en-us/library/ms189822.aspx under Future Keywords





[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-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-397] PostgreSQL - getDateTimeTzFormatString() Created: 12/Dec/12  Updated: 17/Dec/12  Resolved: 16/Dec/12

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

Type: Bug Priority: Major
Reporter: Phill Pafford Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: datetime, dql, format, postgresql
Environment:

PostgreSQL Database



 Description   

In:

  • vendor/doctrine/dbal/lib/Doctrine/DBAL/Platforms/PostgreSqlPlatform.php

The function:

getDateTimeTzFormatString()

only returns one datetime format:

    /**
     * {@inheritDoc}
     */
    public function getDateTimeTzFormatString()
    {
        //return 'Y-m-d H:i:sO'; // original format
        return 'Y-m-d H:i:s.uO'; // format also needed
    }


Here is the error I get using the original format:

Could not convert database value "2012-12-07 16:01:52.580789-05" to Doctrine Type datetimetz. Expected format: Y-m-d H:i:s.O

If I use this format: 'Y-m-d H:i:s.uO' it works.



 Comments   
Comment by Phill Pafford [ 12/Dec/12 ]

adding html tags for code to display correctly

Comment by Benjamin Eberlei [ 16/Dec/12 ]

DateTimeTz is created as 'TIMESTAMP(0) WITH TIME ZONE' on DBAL. If you have 'TIMESTAMP(6) WITH TIME ZONE' instead, then you have to create your own datatye.

Comment by Phill Pafford [ 17/Dec/12 ]

Why would this be a new data type? I understand how to fix the problem with creating my own data type to handle the formatting issue and would even suggest just overriding the data type with

        Type::overrideType('datetimetz', 'Doctrine\DBAL\Types\VarDateTimeType');
    Type::overrideType('datetime', 'Doctrine\DBAL\Types\VarDateTimeType');

But it's not a new data type, it's a formatting issue.





[DBAL-161] Character Set of Database not UTF-8 Created: 07/Sep/11  Updated: 20/Nov/12  Resolved: 05/May/12

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

Type: Bug Priority: Major
Reporter: Hari K T Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None
Environment:

Ubuntu



 Description   

Hi Guys,

I was working with symfony command line and created the database with the app/console doctrine:create:database

Though the characterset I specified was UTF-8 , it created Latin character set .

@elliot was right too, the create database is not using any character set https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Platforms/MySqlPlatform.php#L328

You can see the issue created at https://github.com/symfony/symfony/issues/2044 and later Fabien confirmed the bug is related to Doctrine .

I am not sure its a Bug or a feature I am asking .

Thanks



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

Yes these are not connected, however we changed the default collation to UTF-8 for DBAL 2.3

Comment by Ivan Borzenkov [ 20/Nov/12 ]

not fixed or broken now
doctrine:create:database still create database whis latin1 charset

https://github.com/doctrine/DoctrineBundle/issues/49





[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-65] No way to store binary data in PostgreSQL with Doctrine Created: 20/Nov/10  Updated: 09/Oct/12  Resolved: 20/Nov/10

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

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

PostgreSQL 8.4



 Description   

The type system introduced by Doctrine makes impossible to store binary data in PostgreSQL databases that use Unicode. The `text` type is mapped to `TEXT`, but any trial to place some binary data there ends up with a database error, like this:

SQLSTATE[22021]: Character not in repertoire: 7 ERROR: invalid byte sequence for encoding "UTF8": 0x9c

This is a critical limitation, because Doctrine cannot be used now in projects that for any reasons have to use PostgreSQL, and their databases must store binary data. Even if it cannot be fixed right now, it should be clearly pointed out in the documentation in "Known vendor issues".

A possible solution for this problem is creating an equivalent of 'text' field, called 'binary' or something like that. It must be a simple type that is mapped to the simplest, but large type available in the database engine without any form of data structure validation. For PostgreSQL, this could be 'blob', but other database engines can use different types.



 Comments   
Comment by Tomasz Jędrzejewski [ 20/Nov/10 ]

Just a small note why I consider this bug as quite serious: for many programmers and their projects the lack of both support for such content type and any information about the limitation can be very dangerous. It can be impossible to remove ORM, if such an issue is encountered in the implementation process, and trials to workaround it are time-consuming.

If I'm about to decide whether to use a particular ORM or not, I must have full information about ORM and database-specific limitations.

One more update: shame on me, obviously there is no "blob" type in PostgreSQL; in this database engine binary data could be represented by 'BYTEA'.

Comment by Benjamin Eberlei [ 20/Nov/10 ]

This is not an issue, there are two options to "solve" your problem in userland:

1. Create your own DBAL type - http://www.doctrine-project.org/projects/orm/2.0/docs/reference/basic-mapping/en#custom-mapping-types
2. Use columnDefinition Attribute of @column - http://www.doctrine-project.org/projects/orm/2.0/docs/reference/annotations-reference/en#ann_column

Comment by Tomasz Jędrzejewski [ 12/Dec/10 ]

I know I can create a custom type, but I'd like to have a portable binary type by default in Doctrine DBAL, not reinventing the wheel every time I want to have one. I consider binary data as one of the primitive types that every database engine supports.

Comment by Jon Wadsworth [ 09/Oct/12 ]

This is an old post but just in case somebody else finds it. There is no need to do any of the above to store binary data in Postgres. I had the same situation and was easily solved by compressing file, base64 encoding it, and finally serializing it.

public static function prepareFileforDatabase($file)

{ $compressor = new \Zend_Filter_Compress_Gz(); $file = $compressor->compress($file); $file = base64_encode($file); return serialize($file); }

We use Zend and you may be able to get away with not compressing if you wanted to avoid the extra overhead on your server. To undo it is exactly the opposite.

public static function prepareFileforPHP($file)

{ $compressor = new \Zend_Filter_Compress_Gz(); $file = unserialize($file); $file = base64_decode($file); return $compressor->decompress($file); }

Sorry for the code coming out in all one line, but you get the idea.





[DBAL-108] Runtime error when calling listTables if one of the tables has no index. Created: 07/Apr/11  Updated: 08/Jul/12  Resolved: 08/Jul/12

Status: Resolved
Project: Doctrine DBAL
Component/s: Schema Managers
Affects Version/s: 2.0.3
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: David Leedom Assignee: Juozas Kaziukenas
Resolution: Fixed Votes: 0
Labels: None
Environment:

Windows 2003 Server, MS SQL 2005 express, PHP 5.3.3, IIS 6, fastcgi



 Description   

So I have a table that SHOULD be indexed but is not. But it took me a while to track it down.

Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[IMSSP]: The active result for the query contains no fields.' in D:\Web Sites\Application Development Engine\doctrine-dbal\Doctrine\DBAL\Connection.php on line 532

I tracked the error to fetchAll in Connection.php

There is this line: $this->executeQuery($sql, $params)->fetchAll(PDO::FETCH_ASSOC);

However, when a stored procedure runs and does not return a result set then this produces an error.

I am not sure what the best way to address this is.

In my testing I captured the statement variable and looked at the errorCode. It had an error code of 01000. errorInfo had 15472 and "[Microsoft][SQL Server Native Client 10.0][SQL Server]The object 'Session' does not have any indexes, or you do not have permissions."

The sql was : exec sp_helpindex 'Session' and it just did not have any indexes.

To my mind this should not blow up. Just gracefully handle it.

My thought at this point and what I will change in my code it to return an empty string if no columns are found. That will solve the immediate issue. And possibly hand other stored procedure issues in the future.



 Comments   
Comment by Benjamin Eberlei [ 08/Apr/11 ]

Assigned to Juozas

Comment by Benjamin Eberlei [ 08/Jul/12 ]

This was fixed in October





[DBAL-278] add support for lastInsertId method on OCI8 Driver Created: 16/May/12  Updated: 22/May/12  Resolved: 22/May/12

Status: Resolved
Project: Doctrine DBAL
Component/s: Drivers
Affects Version/s: 2.2.2
Fix Version/s: 2.3

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

oci8



 Description   

The method lastInsertId() is not defined for OCI8 Driver in Doctrine\DBAL\Driver\OCI8\OCI8Connection.php :

OCI8Connection.php
public function lastInsertId($name = null)
{
    //TODO: throw exception or support sequences?
}

I propose this method to handle lastInsertId for sequence :

OCI8Connection.php
public function lastInsertId($name = null)
 {
        // For sequence
        if (is_string($name)) {
            // We can check eventually check the presence of the sequence in the table
            // USER_SEQUENCES
            $sql = 'SELECT ' . $name . '.CURRVAL FROM DUAL';
            // will throw an exception if this sequence does not exist
            $stmt = $this->query($sql);
            $result = $stmt->fetch(\PDO::FETCH_ASSOC);
            if ($result !== false && isset($result['CURRVAL'])) {
                return (int) $result['CURRVAL'];
            }
    }
    // OCI8 driver does not provide support of lastInsertId
    return null;
}

Thanks,






[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-219] wrong schema hadTable and getTable return when table name contains quote Created: 12/Feb/12  Updated: 24/Mar/12  Resolved: 24/Mar/12

Status: Resolved
Project: Doctrine DBAL
Component/s: Schema Managers
Affects Version/s: None
Fix Version/s: 2.2.2

Type: Bug Priority: Minor
Reporter: Alexandru Patranescu Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

wrong schema hadTable and getTable return when table name contains quote.

I bump into this when useing a ManyToMany replation and one Entity was named Group with tablename `Group`
In RemoveNamespacedAssets the FK from The Join Table to Group was removed because in acceptForeignKey() $this->schema->hasTable($fkConstraint->getForeignTableName()) returned false



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

Fixed and merged into 2.2





[DBAL-230] Custom types not taken into account when running $ doctrine orm:validate-schema Created: 05/Mar/12  Updated: 14/Mar/12  Resolved: 14/Mar/12

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

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

Postgres



 Description   

Hi,

I created a class to handle PostgreSQL "inet" type and setup bootstape in order to register this new type.

PostgresInetType.php
namespace Doctrine\DBAL\Types;

class PostgresInetType extends Type {

    const INET = 'inet'; // modify to match your type name

    public function getSqlDeclaration(array $fieldDeclaration, AbstractPlatform $platform) {
        return 'Inet';
    }

    public function convertToPHPValue($value, AbstractPlatform $platform) {
        return new $value;
    }

    public function convertToDatabaseValue($value, AbstractPlatform $platform) {
        if (null === $value) {
            return null;
        } elseif (preg_match("/^((25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?).(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?).(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?).(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?))|((([0-9A-Fa-f]{1,4}:){7}[0-9A-Fa-f]{1,4})|(([0-9A-Fa-f]{1,4}:){6}:[0-9A-Fa-f]{1,4})|(([0-9A-Fa-f]{1,4}:){5}:([0-9A-Fa-f]{1,4}:)?[0-9A-Fa-f]{1,4})|(([0-9A-Fa-f]{1,4}:){4}:([0-9A-Fa-f]{1,4}:){0,2}[0-9A-Fa-f]{1,4})|(([0-9A-Fa-f]{1,4}:){3}:([0-9A-Fa-f]{1,4}:){0,3}[0-9A-Fa-f]{1,4})|(([0-9A-Fa-f]{1,4}:){2}:([0-9A-Fa-f]{1,4}:){0,4}[0-9A-Fa-f]{1,4})|(([0-9A-Fa-f]{1,4}:){6}((b((25[0-5])|(1d{2})|(2[0-4]d)|(d{1,2}))b).){3}(b((25[0-5])|(1d{2})|(2[0-4]d)|(d{1,2}))b))|(([0-9A-Fa-f]{1,4}:){0,5}:((b((25[0-5])|(1d{2})|(2[0-4]d)|(d{1,2}))b).){3}(b((25[0-5])|(1d{2})|(2[0-4]d)|(d{1,2}))b))|(::([0-9A-Fa-f]{1,4}:){0,5}((b((25[0-5])|(1d{2})|(2[0-4]d)|(d{1,2}))b).){3}(b((25[0-5])|(1d{2})|(2[0-4]d)|(d{1,2}))b))|([0-9A-Fa-f]{1,4}::([0-9A-Fa-f]{1,4}:){0,5}[0-9A-Fa-f]{1,4})|(::([0-9A-Fa-f]{1,4}:){0,6}[0-9A-Fa-f]{1,4})|(([0-9A-Fa-f]{1,4}:){1,7}:))$/", $value)) {
            return $value;
        } else {
            throw new PostgresInetTypeException($value);
        }
    }

    public function getName() {
        return self::INET;
    }

}
bootstrap.php
// ... other Doctrine setup stuff

// Define Database driver
$objDBALConfig = new \Doctrine\DBAL\Configuration();

$arrConnectionOptions = array(
    'dbname' => 'my_pg_database',
    'user' => 'itsme',
    'host' => '127.0.0.1',
    'driver' => 'pdo_pgsql',
);

$objDBALConnection = DriverManager::getConnection($arrConnectionOptions, $objDBALConfig);

// Add special PostgresType INET
Type::addType('inet', 'Doctrine\DBAL\Types\PostgresInetType');
$objDBALConnection->getDatabasePlatform()->registerDoctrineTypeMapping('Inet', 'inet');

// Instanciate EntityManager

$objDoctEntityManager = EntityManager::create($objDBALConnection, $objDoctConfig);

// ...

When running

php doctrine.php orm:validate-schema --verbose

I get the following:

[Mapping]  OK - The mapping files are correct.


                                                                                                        
  [Doctrine\DBAL\DBALException]                                                                         
  Unknown database type inet requested, Doctrine\DBAL\Platforms\PostgreSqlPlatform may not support it.  
                                                                                                        


Exception trace:
 () at /var/www/vhosts/workflow/project/Doctrine/DBAL/Platforms/AbstractPlatform.php:261
 Doctrine\DBAL\Platforms\AbstractPlatform->getDoctrineTypeMapping() at /var/www/vhosts/workflow/project/Doctrine/DBAL/Schema/PostgreSqlSchemaManager.php:285
 Doctrine\DBAL\Schema\PostgreSqlSchemaManager->_getPortableTableColumnDefinition() at /var/www/vhosts/workflow/project/Doctrine/DBAL/Schema/AbstractSchemaManager.php:672
 Doctrine\DBAL\Schema\AbstractSchemaManager->_getPortableTableColumnList() at /var/www/vhosts/workflow/project/Doctrine/DBAL/Schema/AbstractSchemaManager.php:159
 Doctrine\DBAL\Schema\AbstractSchemaManager->listTableColumns() at /var/www/vhosts/workflow/project/Doctrine/DBAL/Schema/AbstractSchemaManager.php:254
 Doctrine\DBAL\Schema\AbstractSchemaManager->listTableDetails() at /var/www/vhosts/workflow/project/Doctrine/DBAL/Schema/AbstractSchemaManager.php:242
 Doctrine\DBAL\Schema\AbstractSchemaManager->listTables() at /var/www/vhosts/workflow/project/Doctrine/DBAL/Schema/AbstractSchemaManager.php:830
 Doctrine\DBAL\Schema\AbstractSchemaManager->createSchema() at /var/www/vhosts/workflow/project/Doctrine/ORM/Tools/SchemaTool.php:689
 Doctrine\ORM\Tools\SchemaTool->getUpdateSchemaSql() at /var/www/vhosts/workflow/project/Doctrine/ORM/Tools/SchemaValidator.php:258
 Doctrine\ORM\Tools\SchemaValidator->schemaInSyncWithMetadata() at /var/www/vhosts/workflow/project/Doctrine/ORM/Tools/Console/Command/ValidateSchemaCommand.php:80
 Doctrine\ORM\Tools\Console\Command\ValidateSchemaCommand->execute() at /var/www/vhosts/workflow/project/Doctrine/Symfony/Component/Console/Command/Command.php:187
 Symfony\Component\Console\Command\Command->run() at /var/www/vhosts/workflow/project/Doctrine/Symfony/Component/Console/Application.php:194
 Symfony\Component\Console\Application->doRun() at /var/www/vhosts/workflow/project/Doctrine/Symfony/Component/Console/Application.php:118
 Symfony\Component\Console\Application->run() at /var/www/vhosts/workflow/project/Doctrine/ORM/Tools/Console/ConsoleRunner.php:39
 Doctrine\ORM\Tools\Console\ConsoleRunner::run() at /var/www/vhosts/workflow/project/doctrine.php:36


orm:validate-schema

I throw an eye to DBAL/Platforms/AbstractPlatform.php abstract class and DBAL/Platforms/PostgresSqlPlatform.php implementation. It appears initializeDoctrineTypeMappings() does not care about user custom types that might be declared.



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

Yes, you have to register them manually using AbstractPlatform#registerDoctrineTypeMapping.





[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-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-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-151] Github-PR-50 by dteoh: Made custom Oracle NLS_DATE_FORMAT more compatible with Doctrine. 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: None

Type: Improvement Priority: Major
Reporter: Benjamin Eberlei 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

{username}

:

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

Message:



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

The corresponding PR has been closed





[DBAL-157] Exception given when updating schema Created: 22/Aug/11  Updated: 18/Nov/11  Resolved: 18/Nov/11

Status: Resolved
Project: Doctrine DBAL
Component/s: Schema Managers
Affects Version/s: None
Fix Version/s: 2.1.5

Type: Bug Priority: Minor
Reporter: Chris Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 1
Labels: None
Environment:

Mac OSX 10.6.7
PHP 5.3.4



 Description   

Been experimenting with Symfony2 past days, and somehow managed to generate an Exception in the MySqlSchemaManager Classes of Doctrine.

I've build my schema once, the next time i run the command i'm receiving following error:

[ErrorException]
Notice: Undefined index: default in /Users/chris/Sites/Symfony/vendor/doctrine-dbal/lib/Doctrine/DBAL/Schema/MySqlSchemaManager.php line 157

i can't figure out an error in my classes.

When i drop the database table, i can re-run the command again without exception.. even though another run it will throw it up again.

I've checked the code in line #157, and adpted it slightls:

prev:

'default' => $tableColumn['default'],

modified:
'default' => (isset($tableColumn['default'])) ? $tableColumn['default'] : null,

Can anyone confirm this issue?

Greetings,
Chris



 Comments   
Comment by Chris K [ 25/Sep/11 ]

Hi, I'm also seeing this exact issue using Sf2 and Doctrine. You can't use the console to force update the schema, you have to completely drop all of the tables to get the command to work again. Also using Mac locally.

Comment by Benjamin Eberlei [ 18/Nov/11 ]

Interesting that some MySQL versions dont seem to have the default field then in information_schema?

Comment by Benjamin Eberlei [ 18/Nov/11 ]

Fixed, will be in 2.1.4





[DBAL-144] Oracle tables without indices are not handled during convert - this behavior should be tolerant since Oracle does not require indicies. Created: 02/Aug/11  Updated: 14/Nov/11  Resolved: 14/Nov/11

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

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



 Description   

While it is good practice to always have at least one index defined on every table, in some cases (such as temporary tables) indices are not necessary. Oracle does not enforce creating indices for every table, and it is common to create some tables without them. The Table.php (line 556) method throws an exception if an index is not found for a given table. It's obvious there are ramifications for findByPK( ) auto-generated methods - these should be generated for every case where PK exists to accommodate Oracle and tolerate variances from accepted best-practices with most other database platforms.



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

When does this error happen?

This method is called through Table::getPrimaryKey(). Does this happen during the "doctrine:schema*" toolchain?

Comment by Ed Anderson [ 30/Oct/11 ]

This happens in the doctrine:schema toolchain.

Comment by Benjamin Eberlei [ 14/Nov/11 ]

Fixed.





[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





[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-159] Symfony Doctrine Task "doctrine:database:create" fails with "Undefined index: dbname" Created: 25/Aug/11  Updated: 30/Oct/11