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.

• 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

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.

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..)

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

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

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

Message:

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

We are missing Insert and Merge Query Objects.

See Drupal DBTNG:

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

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