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.

Today exist many customers with Informix 11.50 and they will deveoplment with php+simphony, but doctrine will be an alternative inside the framework but it isn't supported.
My customers can't migration ( they are happy with informix) your application and he need a framework as simphony and an abstration of your environment as Doctrine.
There is a possibility to support Informix in Doctrine?
Thanks and regards

Adolfo Flores
Consultant

SQL statements may contain question marks in strings, inline comments or comment blocks. The current implementation of the method "convertPositionalToNamedPlaceholders()" doesn't consider these implications and falsely replaces them by named bind variables.

Replacement code with example:

<?php
$s = '-- Testkomm?ntar
	select	/* ? *//* ??? */ ?||\'H"al?l"o?\' as "h?""llo" union /* "? Kommentar" \' */
	/* ?" */ select \'/*Hallo\'||to_char( ? ) union select \'--Welt\'
	union--
	select ?';

echo 'In: ' . $s . PHP_EOL;

$bind = 0;
$skip = array( '--' => PHP_EOL, '/*' => '*/', '"' => '"', "'" => "'" );
for( $i = 0; $i < strlen( $s ) /* size of string might change! */; /* yes, no increment here! */ )
{
	// Skipping comments and literals
	foreach( $skip as $begin => $end )
	{
		$matches = substr_compare( $s, $begin, $i, strlen( $begin ) );
		if( $matches !== false && $matches == 0 )
		{
			$pos = strpos( $s, $end, $i+strlen( $begin ) );
			// echo "Found $begin, skipping at $i to $end at $pos" . PHP_EOL;
			if( $pos === false )
			{
				// No more data or illegal statement - anyway: no more replacements!
				// echo "EOD" . PHP_EOL;
				break 2;
			}
			$i = $pos + strlen( $end );
			continue 2; // Ensure we match /*..*//*..*/, '''' or """" - that's why we don't ++$i in the for-loop!
		}
	}
	if( $s[$i] == "?" )
	{
		// Positional to named
		// echo "Replace $bind" . PHP_EOL;
		$r = ':name' . ++$bind;
		$s = substr_replace( $s, $r, $i, 1 );
		$i += strlen( $r );
	}
	++$i;
}

echo 'Out: ' . $s . PHP_EOL;

The following workflow is necessary for portable code to work on all platforms:

$nextId = $conn->nextSequenceId();
$query = "INSERT INTO (id) VALUES (?)";
$conn->executeUpdate($query, array($nextId));
$nextId = $conn->lastInsertId();

$ 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)
));

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

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

Message:

Based on discussion in pull request 188 with @stof, I decided to modify the implementation for Akiban to use the PostgreSQL PDO driver instead of the native PHP client for PostgreSQL.

One piece of functionality that does not work with current version of Akiban is lastInsertId. This is because the implementation of CURRVAL for Akiban requires both schema name and sequence name be provided whereas PostgreSQL only requires sequence name ([relevant source](https://github.com/php/php-src/blob/master/ext/pdo_pgsql/pgsql_driver.c#L360)). I will attempt to get CURRVAL in Akiban implemented to have the same parameters as PostgreSQL.

This causes a few tests to fail in the test suite right now. Is there a way to mark a test as expected to fail for a specific database driver with the test suite? What I did in this pull request is skip any tests that use lastInsertId when testing against the Akiban platform. I'll update these tests to not be skipped when CURRVAL works as expected. Let me know if there is a better way to do that.

When using Doctrine ORM mapping fields like this:

/**

• @var integer
  *
• @ORM\Column(name="id", type="integer", nullable=false)
• @ORM\Id
• @ORM\GeneratedValue(strategy="IDENTITY")
• @ORM\SequenceGenerator(sequenceName="schemaname.tablename_id_seq", allocationSize=1, initialValue=1)
  */
  private $id;

It first creates the migration perfectly as a serial column with the correct schema.

However when making a new migration diff it generates DROP statements for every sequence for these id, so we have to remove them manually every time.

It's currently rather hard to figure out what went wrong when for example a DBALException was thrown. You have to actually match the message in it, or read the status code of the ->getPrevious() exception, which can be different for all drivers (as https://github.com/jackalope/jackalope-doctrine-dbal/issues/80 shows).

I'd suggest creating new exception classes for all situations and throwing them instead. If they extend the DBAL Exception and pass the message to it as it is right now, there will be no BC break.

If this were to be done, on which branch should this be applied?

When using Custom Doctrine DBAL Enums the migration created using diff

works fine the first time.

However the next time it generates a SQL statement trying to change to field type to INT from integer; (Redundant)
and a truncated statement:

"ALTER schemaname.fieldname SET" .. And that's it.

Schema comparator will mostly always return changed properties on columns for entities defined with columnDefinition even they are identical in the DB. This is due to weak low-lever compatibility of SchemaTool#getCreateSchemaSql() and SchemaTool#getSchemaFromMetadata() – the first one doesn't reconstruct columnDefinition, and the other one never supports 'fixed', 'default', cannot determine, whether it is boolean or integer (ex. TINYINT in the DB), etc...

All this results in extremely annoying unnecessary alter-table-change-columns surrounded by dropping and after that re-enabling constrains dependent on those columns.

I mean stuff like this:

...
ALTER TABLE es_hotels DROP FOREIGN KEY FK_527F88EE584598A3F92F3E70;
ALTER TABLE es_hotels DROP FOREIGN KEY FK_527F88EE584598A37A3ABE5D;
ALTER TABLE es_hotels DROP FOREIGN KEY FK_527F88EE584598A3EE551564;
ALTER TABLE es_hotels CHANGE is_active is_active TINYINT(1) NOT NULL DEFAULT '1', CHANGE checksum checksum CHAR(32) DEFAULT NULL;
ALTER TABLE es_hotels ADD CONSTRAINT FK_527F88EE584598A3F92F3E70 FOREIGN KEY (operator_id, country_id) REFERENCES es_countries(operator_id, id) ON DELETE CASCADE;
ALTER TABLE es_hotels ADD CONSTRAINT FK_527F88EE584598A37A3ABE5D FOREIGN KEY (operator_id, resort_id) REFERENCES es_resorts(operator_id, id) ON DELETE CASCADE;
ALTER TABLE es_hotels ADD CONSTRAINT FK_527F88EE584598A3EE551564 FOREIGN KEY (operator_id, subresort_id) REFERENCES es_subresorts(operator_id, id) ON DELETE CASCADE;
...

The simple solution would be to fix schema comparator not to signal any changes on columns with columnDefinition properties.
But would be much and much better to add some code to all *SchemaManager#getPortableTableColumnDefinition so they would reconstuct columnDefinition and they would be matched in the schema comparator.

I can do this

Hi,

In OCI8Statement, using PDO::FETCH_NUM does not work because the fetch style mapping is overwritten by PDO::PARAM_LOB since the two has the same value (3);

protected static $fetchModeMap = array(
PDO::FETCH_BOTH => OCI_BOTH,
PDO::FETCH_ASSOC => OCI_ASSOC,
PDO::FETCH_NUM => OCI_NUM,
PDO::PARAM_LOB => OCI_B_BLOB,
PDO::FETCH_COLUMN => OCI_NUM,
);

so PDO::FETCH_NUM is mapped to OCI_B_BLOB

It's not possible to use char fields in the ORM layer.

It should be possible to use something like:

@Column(type="char") or ...
@Column(type="string", fixed=true) or ...
@Column(type="fixedstring")

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.

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.

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.

• 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

• http://savage.net.au/SQL/sql-92.bnf See <actual identifier>
• http://www.alberton.info/dbms_identifiers_and_case_sensitivity.html

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

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

For a query such as

x = CASE WHEN id=$1 THEN CAST($2 AS int)

there doesn't seem to be a way to correctly assign the type across multiple platforms. E.g. Postgres required "int" but mysql just requires "unsigned". Attempting to use "int" here with mysql will fail.

The method Doctrine\DBAL\Platforms method getIntegerTypeDeclarationSQL will return something like "INT unsigned" for sql, which also fails.

Hi,
I want to update my schema but I am getting the following error message:

[Doctrine\DBAL\Driver\OCI8\OCI8Exception]
ORA-01442: column to be modified to NOT NULL is already NOT NULL

--dump-sql says:

ALTER TABLE CONSIGNMENTS MODIFY (SDGDATE  DATE DEFAULT NULL);

The current table structure looks like that:

Mapping definition:

/**
 * @ORM\Column(name="SDGDATE",type="date",nullable=true)
 */
private $sdgdate;

I think there is a problem with the comparison between Oracles 'Date' type and the Metadata 'Date' type. I am used to use MySQL as DBMS but our customer uses Oracle. MySQL's 'datetime' and Oracle's 'date' type are store the same data.

I am not sure what should be done here. Because this could lead to confusion for all Oracle user.

Maybe there could be a request to the platform in the Schema Comparator here:

public function diffColumn(Column $column1, Column $column2)
{
    $changedProperties = array();
    if ( $column1->getType() != $column2->getType() ) {
        $changedProperties[] = 'type';
    }
    // ...
}

Generation of any SQL command to the database (From entities or migration versions) does not quote all the reserved keywords (For example a fieldname `right`.

Simple fix that always works: double-quote dbname, schemaname and fieldname

e.g "dbsecurity"."userschema"."users" or "tblusers"

MySQL : use the ` sign.

e.g `security`.`users` or `tblusers` (No support for schemas since I last checked some time ago)

I have an installer script that uses ORM SchemaTool to create the entities in the DB and then populates with basic data using basic EM->persist calls via ORM.

Sequence objects are created, and when using the 10g Instant Client everything worked correctly, however, upon upgrade to latest version of the Instant Client Oracle seems to be expecting consistent case for these schema objects. It appears as if they are being created with a quoted name as they are created in lowercase. OraclePlatform::getSequenceNextValSQL, however, generates "SELECT entity_id_seq.nextval FROM DUAL" and this fails with error "General error: 2289 OCIStmtExecute: ORA-02289: sequence does not exist".

Executing "SELECT "entity_id_seq".nextval FROM DUAL" directly on the DB returns the correct value.

I believe this may also impact the code in http://www.doctrine-project.org/jira/browse/DBAL-278

Please add support for uuid datatype in PostgreSQL

Should be useful discover the table comments from database schema.

This feature is already available for column comments, but not for table comments

getVarcharMaxLength() in DBAL/Platforms/MySqlPlatform.php returns 65535;
So, it never choose "text", choose "mediumtext".

In SQLServerPlatform the default length for a VARCHAR declaration is set to "255". But according to the SQLServer documentation from Microsoft the default length is "1", if omitted in the declaration.
See remarks: http://msdn.microsoft.com/en-us/library/ms186939.aspx
Also the default length is hardcoded in the "getVarcharTypeDeclarationSQLSnippet" method which in my opinion should be evaluated through "getVarcharDefaultLength".

I don't exactly know if the current implementation is intended, otherwise it should be fixed. I would then create an PR if desired.

A table in this application had no primary keys. I created an entity
so i could attempt to use the doctrine:schema:update command to fix it up.

When i attempted to add this:

• @ORM\Id
• @ORM\GeneratedValue(strategy="NONE")

to this:

• @ORM\Column(name="session_id", type="string", length=128,
  nullable=false)

it generates SQL like this:

ALTER TABLE whos_online DROP INDEX idx_session_id_zen, ADD UNIQUE INDEX primary (session_id);
ALTER TABLE whos_online CHANGE ip_address ip_address VARCHAR(45) NOT NULL, CHANGE host_address host_address VARCHAR(512) NOT NULL;

and says this:

An exception occurred while executing 'ALTER TABLE whos_online DROP INDEX idx_session_id_zen, ADD UNIQUE INDEX primary (session_id );
SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to
your MySQL server version for the right syntax to use near 'primary (session_id)' at line 1

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.

if i want to change a tablename the foreign key doesnt change and i get an error

$config = new Doctrine\DBAL\Configuration();
$conn = Doctrine\DBAL\DriverManager::getConnection($conn, $config);
$sm = $conn->getSchemaManager();
foreach ($sm->listTables() as $table) {
$fromSchema = $sm->createSchema();
$toSchema = clone $fromSchema;
$toSchema->renameTable($table->getName(), str_replace("_new", "", $table->getName()));
$sql = $fromSchema->getMigrateToSql($toSchema, $conn->getDatabasePlatform());
foreach ($sql as $query)

}

##################################################
CREATE TABLE doc_consultant_practice (consultant_id INT NOT NULL, practice_id INT NOT NULL, INDEX IDX_60C69DE344F779A2 (consultant_id), INDEX IDX_60C69DE3ED33821 (practice_id), PRIMARY KEY(consultant_id, practice_id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB
ALTER TABLE doc_consultant_practice ADD CONSTRAINT FK_60C69DE3ED33821 FOREIGN KEY (practice_id) REFERENCES doc_xml_practice_new (id) ON DELETE CASCADE
ALTER TABLE doc_consultant_practice ADD CONSTRAINT FK_60C69DE344F779A2 FOREIGN KEY (consultant_id) REFERENCES doc_xml_consultant_new (id) ON DELETE CASCADE
DROP TABLE doc_consultant_practice_new
##################################################
Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[42S01]: Base table or view already exists: 1050 Table 'doc_xml_consultant_new' already exists' in /Applications/MAMP/bin/php/php5.3.14/lib/php/Doctrine/ORM/Tools/ToolsException.php on line 33

PDOException: SQLSTATE[42S01]: Base table or view already exists: 1050 Table 'doc_xml_consultant_new' already exists in /Applications/MAMP/bin/php/php5.3.14/lib/php/Doctrine/DBAL/Connection.php on line 646

Call Stack:
0.0178 766208 1.

() /PATH/TO/jobs/import.php:0
0.0430 771936 2. require_once('/PATH/TO/jobs/config.php') /PATH/TO/jobs/import.php:7
0.0528 775448 3. require_once('/PATH/TO/jobs/bootstrap.php') /PATH/TO/jobs/config.php:3
0.0623 812680 4. require_once('/PATH/TO/jobs/bootstrap_doctrine.php') /PATH/TO/jobs/bootstrap.php:5
16.7866 16304048 5. Doctrine\ORM\Tools\SchemaTool->createSchema() /PATH/TO/jobs/bootstrap_doctrine.php:70
16.8798 16562624 6. Doctrine\DBAL\Connection->executeQuery() /Applications/MAMP/bin/php/php5.3.14/lib/php/Doctrine/ORM/Tools/SchemaTool.php:90

Doctrine\ORM\Tools\ToolsException: Schema-Tool failed with Error 'An exception occurred while executing 'CREATE TABLE doc_xml_consultant_new (id INT NOT NULL, name VARCHAR(255) DEFAULT NULL, email VARCHAR(255) DEFAULT NULL, lastCommaFirstName VARCHAR(255) DEFAULT NULL, education LONGTEXT DEFAULT NULL, workHistory LONGTEXT DEFAULT NULL, imageStandard VARCHAR(255) DEFAULT NULL, imageWide VARCHAR(255) DEFAULT NULL, PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB':

SQLSTATE[42S01]: Base table or view already exists: 1050 Table 'doc_xml_consultant_new' already exists' while executing DDL: CREATE TABLE doc_xml_consultant_new (id INT NOT NULL, name VARCHAR(255) DEFAULT NULL, email VARCHAR(255) DEFAULT NULL, lastCommaFirstName VARCHAR(255) DEFAULT NULL, education LONGTEXT DEFAULT NULL, workHistory LONGTEXT DEFAULT NULL, imageStandard VARCHAR(255) DEFAULT NULL, imageWide VARCHAR(255) DEFAULT NULL, PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB in /Applications/MAMP/bin/php/php5.3.14/lib/php/Doctrine/ORM/Tools/ToolsException.php on line 33

Call Stack:
0.0178 766208 1.

() /PATH/TO/jobs/import.php:0
0.0430 771936 2. require_once('/PATH/TO/jobs/config.php') /PATH/TO/jobs/import.php:7
0.0528 775448 3. require_once('/PATH/TO/jobs/bootstrap.php') /PATH/TO/jobs/config.php:3
0.0623 812680 4. require_once('/PATH/TO/jobs/bootstrap_doctrine.php') /PATH/TO/jobs/bootstrap.php:5
16.7866 16304048 5. Doctrine\ORM\Tools\SchemaTool->createSchema() /PATH/TO/jobs/bootstrap_doctrine.php:70

Index and foreign key name change is not synced by Comparator.

This is important since in some complex queries one might use FORCE INDEX (some_index_name), and they will fail if an index name is incorrect.

Comparator does not synchronize column order. It would be great if it did.

Problem happens when initially, as example, there was commented type "foo" registered and used:

Doctrine\DBAL\Types\Type::addType('foo', 'FooType');
$em->getConnection()
    ->getDatabasePlatform()
    ->markDoctrineTypeCommented(Doctrine\DBAL\Types\Type::getType('foo'));

When the type usage and declaration is removed, the database schema upgrade fails.
This is because DBAL reads the comment from the database and tries to find the type 'foo'.

I suggest ignoring the database column comment and stick to the standard type recognition in case the type is not declared.

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

For table with text field description with index on it generated query is:

CREATE TABLE t (id INT UNSIGNED AUTO_INCREMENT NOT NULL, description LONGTEXT DEFAULT NULL, number INT DEFAULT NULL, INDEX index2 (description), INDEX index3 (description, number), PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB

This query lead to error, because for index on text field absented key length.

When updating the nullable status of a column the sql generated is

ALTER TABLE MET MODIFY (METAR VARCHAR2(2000) DEFAULT NULL)

This will set the default column value to null but does not modify the nullable status of the column. The correct sql would be

ALTER TABLE MET MODIFY (METAR VARCHAR2(2000) NULL)

The field definition changed from

metar:
type: string
length: 2000
nullable: false
column: METAR

to

metar:
type: string
length: 2000
nullable: true
column: METAR

Dear Symfony team,

the filterExpression on AbstractSchemaManager seems not to work for sequences.

This only happens under postgres.

It seems the way the sequences are handled are the culprit: It tries to get min_value etc of sequences without matching sequence names to the filter expression in advance.

If for example access to the sequences is denied, (Different schema without permissions for the current entity manager), any higher-level ORM operations like generating migration versions fail.

--------------------- UPDATE

the context is when using migrations. Positive regexp expressions do not limit the migration to a single schema. eg ^schemaname.$
Instead, all sequences on the current database are returned.
When trying to limit a migration to a single schema consecutively this doesn't work.
We are using a per-schema connection, so this results in a lot of hassle for us.

When using backticks around table-names (for example "`Order`"), the Doctrine schema update tool wants to recreate all foreign keys on every run.

This error was introduced in commit cb3ec49cb4401bd1c8be6ba9671f651802586eaf

Please see https://github.com/doctrine/migrations/issues/99 for additional background.

To reproduce:

CREATE SCHEMA test_schema;
CREATE TABLE test_schema.test_table (test_column TEXT);

Then in Doctrine:

$connection->executeUpdate('SET search_path=test_schema;');
$result = $connection->getSchemaManager()->tablesExist(array('test_schema.test_table'));

$result is false when it should be true.

The error occurs because PostgreSqlSchemaManager returns the bare table name from getPortableTablesList() if the schema is the first one in the search path.

The full explanation is...

AbstractSchemaManager::tablesExist() calls $this->getPortableTablesList() before checking if the tables exist.

PostgreSqlSchemaManager overrides this in _getPortableTableDefinition() by comparing the schema for the table with the search path for the connection. If the table schema is the first one in the search path, then it returns the bare table name, if it isn't then it returns the schema-qualified table name (i.e. schema.table).

tablesExist() does an array_intersect to check that all the tables in the search array exist in the database.

If one of the tables in the search array was schema-qualified but also in the first schema on the search path, then you end up checking:

array_intersect(array('test_schema.test_table'), array('test_table'))

which fails.

One way to fix it would be to override tablesExist() in PostgreSqlSchemaManager so that it passes the search array through getPortableTableDefinition() before doing the array_intersect:

    /**
     * Return true if all the given tables exist.
     *
     * @param array $tableNames
     * @return bool
     */
    public function tablesExist($tableNames)
    {
        foreach ($tableNames as $key => $tableName) {
            if (strpos($tableName, '.') !== false) {
                $tableName = explode('.', $tableName, 2);
                $tableNames[$key] = $this->_getPortableTableDefinition(array('schema_name'=>$tableName[0], 'table_name'=>$tableName[1]));
            }
        }
        return parent::tablesExist($tableNames);
    }

I'm happy to provide a PR on GitHub if you want.

I using the Doctrine Migrations and when I declared my entity with the indexes section, the index name has been ignored. It's like this:

indexes:
IDX_ADDRESS_CITY:
columns: city_id

but, the diff tools ignore it and give me this code:
$this->addSql("CREATE INDEX IDX_7299B5238BAC62AF ON tb_address (city_id)");

and it should be:
$this->addSql("CREATE INDEX IDX_ADDRESS_CITY ON tb_address (city_id)");

Notice: I open the same bug on the migrations repository in github and @kimhemsoe told me to open here, since this is generated by DBAL component.

Shell output from my symfony project:
$ app/console doctrine:schema:update --force
Updating database schema...

[Doctrine\DBAL\DBALException]
An exception occurred while executing 'ALTER TABLE Tn ADD CONSTRAINT FK_3504C6F07D3656A4 FOREIGN KEY (account) REFERENCES Account (id)':

SQLSTATE[42000]: Syntax error or access violation: 1072 Key column 'account' doesn't exist in table

[PDOException]
SQLSTATE[42000]: Syntax error or access violation: 1072 Key column 'account' doesn't exist in table

doctrine:schema:update [--complete] [--dump-sql] [--force] [--em[="..."]]

$ app/console doctrine:schema:update --force
Updating database schema...
Database schema updated successfully! "7" queries were executed
$

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.

The Postgres Schema code is very hard to read and inconsistent across the board. Some use pg_class, some pg_tables. Namespaces /Schema are not always properly checked for. There should be a really unified way on how to approach schema query issues.

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.

Upsert support in DBAL (replace, insert into usw..)

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

:

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

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

:

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

Message:

Regression test for the following change: https://github.com/doctrine/dbal/commit/2434d95aab231273eea8fb555155e9e9c195bcc9

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

:

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

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

:

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

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

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

Message:

serialize() returns binary data (NUL bytes) and not all platforms
handle that in CLOB fields (e.g. PostgreSQL).

This change uses base64 encoding to work around that, and transparently
reads (old) non-base64 data as well.

Fixes DBAL-368

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

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

Message:

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

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

Message:

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

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

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

Message:

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

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

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

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

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

Message:

With

$db = \Doctrine\DBAL\DriverManager::getConnection($connectionParams, $config);
$qb = $db->createQueryBuilder();

this QueryBuilder I'm able to do SELECT, UPDATE and DELETE. However, INSERT is not possible. Are there any good reasons for this?

Attached you find a patch that until now works fine for me. I don't know, however, if there are any side effects.

This issue is created automatically through a Github pull request on behalf of Tim-Erwin:

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

Message:

See also http://www.doctrine-project.org/jira/browse/DBAL-320
Please review and commit as fits.

Allow to switch a CommitFailure into a successful event.

This could be done by saving all insert/update/delete statements starting from begin transaction and then replaying them N-times until success is achieved.

The following schema-level changes have to be done before tables are created:

• create Schema (PGSQL, MySQL, ...)
• Create Federations (Azure)
• Create Types (PGSQL, Oracle, ...)
• Create Views, Stored Procedures, Triggers

We should add the following APIs:

array $sql AbstractPlatform::getCreateSchemaAdditionalStatements(Schema $schema);
$object = new SQLObject($sqlUpCommand, $sqlDropCommand);
$schema->addSQLObject($object);

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

We are missing Insert and Merge Query Objects.

See Drupal DBTNG:

Merge: http://drupal.org/node/310085
Insert: http://drupal.org/node/310079

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

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

Message:

I am packaging the DoctrineDBAL PEAR package for Fedora and RHEL (EPEL) and would like to have the following updates:

• package.xml role for LICENSE changed from "data" to "doc"

• package.xml role for Doctrine/DBAL/README.markdown changed from "data" to "doc"

• add some content to Doctrine/DBAL/README.markdown (when building RPM this file throws a warning because it is empty)

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

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

Message:

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

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

Message:

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

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

Message:

If results are requested using fetch method FETCH_COLUMN, and the cache is used, the exception is raised:

Invalid fetch-style given for caching result

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

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

Message:

Basically the same feature wanted as in #245

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

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

Message:

Postgre use ISO 8601 date formats so some times can be Y-m-d H:i:s or sometime Y-m-d H:i:s.u