Format code sample

What is wrong here? The error alone is not very helpful

Linux, Unix & Windows

There is a possibility to support Informix, this is described here:

http://www.doctrine-project.org/docs/dbal/2.0/en/reference/supporting-other-databases.html

I don't know informix and never worked with it, if you would volunteer to code this i would be enternelly grateful I could help you with the details of implementation.

I think a working prototype can be implemented in 4-6h of time.

good idea, I am an expert in informix database and I may need support in doctrine.

Is there any template to follow? I have read the required structure in the url given, it seems feasible.

What next step?

I am installing Informix, php 5.3 on RHES 5.2 All 32-bit

Regards,

Adolfo

Note: .I have no time basis, so that one week would be a reasonable time for this activity

I added some more details to the chapter, here is the part:

Implementation Steps in Detail
------------------------------

1. Add your driver shortcut to class-name `Doctrine\DBAL\DriverManager`.
2. Make a copy of tests/dbproperties.xml.dev and adjust the values to your driver shortcut and testdatabase.
3. Create three new classes implementing ``\Doctrine\DBAL\Driver\Driver``, ``\Doctrine\DBAL\Driver\Statement``
and ``Doctrine\DBAL\Driver``. You can take a look at the ``Doctrine\DBAL\Driver\OCI8`` driver.
4. You can run the testsuite of your new database driver by calling "cd tests/ && phpunit -c myconfig.xml Doctrine/Tess/AllTests.php"
5. Start implementing AbstractPlatform and AbstractSchemaManager. Other implementations should serve as good example.

Essentially Driver, Statement are the PDO equivalents of "PDO" and "PDOStatement", they even have the exact same API. OCI8 is a good example to see how it works. If Informix works with PDO then its even simpler, take a look at Doctrine\DBAL\Driver\PDO namespace, you don't need to implement the connection and statement then, just the driver taking care of the configuraiton.

The most complicated thing is to get the Platform and SchemaManager to work. Both are responsible for SQL generation for DDL statements for example. It makes sense to run the phpunit testsuite and fix the bugs when occuring until all tests pass.

Also looking at the platform and schema managers of other databases is a very good help

This algorithmus is painfully slow. There has to be something better, why do you need to foreach the loop inside the for?

Ok, sent you a PM but I'll put my response here, too:

"Painfully slow" at what circumstances? Benchmarks?

This was meant as an example implementation to show the problems of the current implementation - there's always room for improvement.

And never forget: Premature optimization is the root of all evil! ;-p

You want speed - try this one:

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

echo 'In: ' . $sql . PHP_EOL;

$map = array();
for( $cnt = 0; $cnt < 1000; ++$cnt )
{
        $bind = 0;
        $s = $sql;

        if( isset( $map[$s] ) )
                continue;

        $strlen = strlen( $s );
        for( $i = 0; $i < $strlen /* size of string might change! */; /* yes, no increment here! */ )
        {
                $c1 = $s[$i];
                $c2 = isset( $s[$i+1] ) ? $s[$i+1] : '';
                if( $c1 == '-' && $c2 == '-')
                {
                        $pos = strpos( $s, PHP_EOL, $i+2 );
                        if( $pos === false )
                        {
                                break 2;
                        }
                        $i = $pos + 2;
                }
                elseif( $c1 == '/' && $c2 == '*' )
                {
                        $pos = strpos( $s, '*/', $i+2 );
                        if( $pos === false )
                        {
                                break 2;
                        }
                        $i = $pos + 2;
                }
                elseif( $c1 == '"' )
                {
                        $pos = strpos( $s, '"', $i+1 );
                        if( $pos === false )
                        {
                                break 2;
                        }
                        $i = $pos + 1;
                }
                elseif( $c1 == "'" )
                {
                        $pos = strpos( $s, "'", $i+1 );
                        if( $pos === false )
                        {
                                break 2;
                        }
                        $i = $pos + 1;
                }
                elseif( $c1 == "?" )
                {
                        // Positional to named
                        // echo "Replace $bind" . PHP_EOL;
                        $r = ':name' . ++$bind;
                        $s = substr_replace( $s, $r, $i, 1 );
                        $rLen = strlen( $r );
                        $i += $rLen;
                        $strlen += $rLen - 1;
                }
                else
                        ++$i;
        }
        $map[$sql] = $s;
}
echo 'Out: ' . $map[$sql] . PHP_EOL;

ATTENTION: Each "break 2;" means, you have an invalid statement! Do, whatever the statement class is supposed to do in this case!

Regards, Carsten

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

Formatting

PostgreSQL

This should be done in the master branch.

Another solution, avoiding to create many classes, would be to use the exception code, which is always kept as 0 currently (the default value of the Exception class). You could have a code for each case (with constants in the DBALException class) and then checking $e->getCode() to identify what went wrong.

I'd prefer actual named exceptions. It makes catching them simpler. However, adding some code defined in DBAL would be an acceptable alternative.

try {
    /* ... /*
} catch (NoSuchTableException $e) {
    // do something
} catch (DuplicateKeyException $e) {
    // do something else
}

v.s.

try {
    /* ... /*
} catch (DBALException $e) {
    if ($e->getCode() == DBALException::NO_SUCH_TABLE) {
        // do something
    } elseif ($e->getCode() == DBALException::DUPLICATE_KEY) {
        // do something else
    } else {
        throw $e;
    }
}

I would also prefer named exceptions. You're going to have a lot of problems providing the "code" value in DBALException in any case: SQLSTATE codes are alphanumeric, and will cause warnings/errors when creating new exception.

Besides we can get the SQL state code now:

    try {
        // ...
    } catch (\Doctrine\DBAL\DBALException $e) {
        $code = $e->getPrevious()->getCode();
        // do stuff with $code
    }

The problem is that there are a lot of error codes defined in the ANSI SQL standard: http://www.postgresql.org/docs/9.2/static/errcodes-appendix.html

Maybe throwing an specific exception for each "class" of SQLSTATE codes? So if the error code from a PDO exception starts with 23, DBAL would throw `\Doctrine\DBAL\Exception\IntegrityConstraintViolationException`.

This also seems like the logic to handle throwing exceptions should be contained in the platforms as some implementations may differ. You could have a method in `AbstractPlatform` that takes care of the ANSI SQLSTATE error code classes and leave it up subclasses to deal with platform specific cases. Whenever `Connection` catches a `PDOException`, dispatch it to the platform to deal with.

Example: https://gist.github.com/chrisguitarguy/e021918900e93dca304d

Thoughts?

I have implemented a thing of that kind in a personal project (on top of Doctrine). It is really useful to be able to catch a ForeignKeyViolationException, and get with entity/field caused the problem (for that my EntityManager wrapper parse the exception message).

However, note that exception codes differ from DB engines. In my case, I did it quick and used MySQL error codes, but managing different RDBMS implies more work.

postgresql

Doesn't only happen on Enums. I don't use any enums and I have this problem. I use a couple of geo (postGIS) fields (point, linestring, polygon) as well as array fields, so either or all of those might be causing it, too.

We did some changes for PostgreSQL column diffs lately, can you verify this bug still exists on the 2.3 Branch of DBAL?

I'm running this on Symfony2 with this composer.json config:

"doctrine/orm": "2.3.*",
"doctrine/doctrine-bundle": ">=2.1",

and I'm still getting this issue today.

I'm having the same issue on my production webserver, but not on the development webserver. I find that odd. It tries to drop all foreign keys and create them again, although without the CHANGE statement you are referring to, Dmitry.

This maybe fixable by making a hash out of the column definition and saving it into a database comment.

The Foreign Key problem maybe because of an old MySQL version 5.0.x

@beberlei, sounds good to me. any plan of implementing this?

N/A

I dont think this is worth including in the main distribution. A char does not save much compared to a varchar (1 Byte?) and you already have 2 options to make a char:

• create your own custom type (i.e. FixedString)
• Use @Column(..., columnDefinition="CHAR(2)")

IMHO, just use a string type with the length you want: @Column(type="string", length=2). That becomes a varchar with length 2.

Ya, it is only 1 extra byte. I'm not sure what to do, I like things as optimized as possible, but I guess I could just use columnDefinition if necessary.

Actually, I don't really see any reason not to include the char type.

How about code bloat?

How many LoC?

@darkangel Around 40. And lots of conditionals, which decreases efficiency of algorithm.

I vote for FixedString DBAL DataType.

We will not put every special data type someone comes up with in the core library. If we go this route, at the end we have 100+ data types (100+ classes plus a bloated type map) in the core library.

There are at least 2 decent options of making a char already if you care about byte counting (see above).

"Why not?" is not the question to ask for when it comes to new features. If it were, we would include a whole lot of stuff that is useless for 99% of the users. There must be strong arguments for "Why?" and there are none.

If we get 50+ votes on this issue we can talk again.

Of course not. I didn't know that char was a special data type (especially since it's supported in DC1.2).

I will use @columnDefinition.

You may close this issue.

No need to become defensive. There is still the chance that demand for this particular type gets very high and that can change things.

Thats why this stays open. Otherwise the next guy would probably just create a duplicate ticket (not sure whether non-owners can reopen other tickets).

@Glen

The problem with Doctrine 1 and having lots of different data-types is that of maintainability. You have to ensure that all the types work on all supported platforms with each and every version. The more datatypes we support by default the more complex will it be for the Doctrine 2 Core to ensure compability and maintainability in this regard.

For each new platform that we will support all datatypes have to be supported for example, something that might even become impossible for some databases.

Adding a datatype from the user perspective is rather simple though, it has to be tested once and is only about 20-40 LOC. I bet you 100 bucks that soon there will be code-snippets out there on all the different database specific types as a doctrine 2 implemention.

@Roman
Not being defensive, I have accepted/respected your decision.

@Benamin
I did think about cross-database compatibility. As far as I know, char is supported by the vast majority (or at least easily simulated). But I understand.

Thanks.

Sorry for party rocking but i think that 'fixed' annotation should be enabled in ORM column definitions.
In this case @Column(type="string", length=4, fixed=true) would result in "CHAR(4)" for MySQL, Oracle and Postgres, Sqlite, and DB2, "NCHAR(4)" for MQSQL. etc... It is much more elegant than that columnDefinition.
It is already supported by DBAL as well as 'default' heartlessly removed (DDC-100) from annotation driver due to bizzare reluctance to deal with proper escaping of values.

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

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