With Taggable extension, when I try to delete a record using Taggable, I get this exception :

SQLSTATE[23000]: Integrity constraint violation: 1451 Cannot delete or update a parent row: a foreign key constraint fails (`sf_sandbox/article_taggable_tag`, CONSTRAINT `article_taggable_tag_id_article_id` FOREIGN KEY (`id`) REFERENCES `article` (`id`))

If I check the sql queries generated by Doctrine, there are not "onDelete CASCADE" for one of relation added by Taggable extension.

I have write some test cases for reproduce this bug (checking if relation has a property onDelete setted to CASCADE) but I can't reproduce the thrown exception in test case because sqlite omits queries with constraint. Also, I found how to fix this bug.

The fix and test cases are available in the file attached to this ticket.

I've the same problem than this post : http://groups.google.com/group/doctrine-user/browse_thread/thread/3737fd293fef5fda/d86a8bc2578e4bac

Then, I've set "uniqueBy: [name, type] ", and my data goes in database BUT they can have the same slug.

So I can't retrieve an objects wich has equal slug with another.

The column aggregation inheritance does'nt take care of others slugs.

When using the Doctrine_Record::option('orderBy', ...) feature on a table definition, where that table is the target of a many-to-many join, the specified orderBy columns are applied to the relation table's alias. So for example, given the following definitions:

class User extends Doctrine_Record {
  public function setTableDefinition() {
    $this->hasColumn('uid', 'integer', null, array('primary' => true));
    $this->option('orderBy', 'uid');
  }

  public function setUp() {
    $this->hasMany('Group as groups', array('refClass' => 'UserGroup', 'local' => 'user_uid', 'foreign' => 'group_id'));
  }
}

class Group extends Doctrine_Record {
  public function setTableDefinition() {
    $this->hasColumn('gid', 'integer', null, array('primary' => true));
  }

  public function setUp() {
    $this->hasMany('User as users', array('refClass' => 'UserGroup', 'local' => 'group_gid', 'foreign' => 'user_id'));
  }
}

class UserGroup extends Doctrine_Record {
  public function setTableDefinition() {
    $this->hasColumn('user_uid', 'integer', null, array('primary' => true));
    $this->hasColumn('group_gid', 'integer', null, array('primary' => true));
  }

  public function setUp() {
    $this->hasOne('User as user', array('local' => 'user_uid', 'foreign' => 'uid'));
    $this->hasOne('Group as group', array('local' => 'group_gid', 'foreign' => 'gid'));
  }
}

the following queries:

$query = Doctrine_Query::create()
  ->select('u.*')
  ->from('User u')
  ->leftJoin('u.groups g WITH g.gid=?', 1);
echo $query->getSqlQuery() . "\n";

$query = Doctrine_Query::create()
  ->select('g.*')
  ->from('Group g')
  ->leftJoin('g.users u WITH u.uid=?', 1);
echo $query->getSqlQuery() . "\n";

will output the following:

SELECT u.uid AS u__uid FROM user u LEFT JOIN user_group u2 ON (u.uid = u2.user_uid) LEFT JOIN group g ON g.gid = u2.group_id AND (g.gid = ?) ORDER BY u.uid
SELECT g.gid AS g__gid FROM group g LEFT JOIN user_group u2 ON (g.gid = u2.group_gid) LEFT JOIN user u ON u.uid = u2.user_id AND (u.uid = ?) ORDER BY u.uid, u2.uid

The orderBy option() call is applied to the User definition. The SQL for the first query is correct (where User is on the left side of the join). The SQL for the second query (where User is on the right-most side of the join), however, is obviously incorrect (UserGroup doesn't even have a uid column). Basically, User's orderBy option is being applied to both the User table and its respective reference table, UserGroup, when it is the target of a join.

After digging through the source for a while, I believe I've come up with a patch for this issue (which should be checked by someone more knowledgeable of Doctrine's internals). Basically, in the Doctrine_Query::buildSqlQuery() function, a call is made to Doctrine_Relation::getOrderByStatement() with the reference table (UserGroup)'s alias (u2), which in turn makes a call to Doctrine_Table::getOrderByStatement() on the referenced table (User), filling in the ORDER BY clause with User columns using UserGroup's alias. My solution was to reorder the logic so that the test for a reference class is made before the initial call to getOrderByStatement() is made. It seems to work against my test case and the test cases in the repository. I'll post my patch momentarily.

This bug was first mentioned in the comments in DC-313, but the original ticket comes across as more of a feature request for the hasMany() orderBy feature.

I need to override the LANG column size on i18n tables, so I can use "pt_BR" language. I'd like the LANG column to be varchar(5) and not char(5) as it happens if I modify the field length to 5.

I've also tried to set the "fixed" option as false, but I noticed that the I18n generator overrides this option (I18n.php - line 98).

The only workaround I could find was setting the length option as null and the type as varchar(5), but at least for me, it doesn't seem to be the most correct way to define it.

I'd suggest modifying the I18n table definition generator to not override this option.

I've attached a patch with the proposed fix.

The problem was already described by another person at http://trac.symfony-project.org/ticket/7763
the generated field-type is wrong, so the stored lat/long values have lost precision.

Mi Doctrine_Query with this Geometric Query fails with orderBy , but with where works.

$distance = "glength(linestringfromwkb(linestring(GeomFromText('POINT( ".$object->getLatitude()." ".$object->getLongitude() .")'),l.point))) "

This works:
SomeObjectTable::getInstance()>createQuery()>where($distance.' < ?',0.05 )

But this one fails at version 1.2.4, with older version was working.
SomeObjectTable::getInstance()>createQuery()>where($distance.' < ?',0.05 )->orderBy($distance)

Well the problem is at line 74 of OrderBy.php :
$componentAlias = implode('.', $e);

the rendered query in the distance has some ".", for example:
POINT( -34.470829 -58.5286102)

then the after line 74 in OrderBy tries to search por '58' class.

I manually added to DataDict in Mysql.php the POINT datatype (this fix solve me the problem in older versions of Doctrine).

I am trying to generate migrations from the CLI but I get the error mentioned in the title. I did some searching and this seems to have been a known problem and was fixed, however, I'm getting it and the path is correct, and there is even a schema.yml file I just generated, also through CLI.

Here is the error:

D:\wamp\www\project\src\administrator\components\com_project\doctrine>php doctrine generate-migrations-diff
No php or yml files found at path: "D:\wamp\www\project\src\administrator\components\com_project\doctrine\schema"

And here is what I have in my CLI file:

require_once('../../../../libraries/doctrine/lib/Doctrine.php');

spl_autoload_register(array('Doctrine','autoload'));

Doctrine_Manager::connection('mysql://root@localhost/project','default');

//Doctrine_Manager::getInstance()->setAttribute(Doctrine::ATTR_TBLNAME_FORMAT, 'jos_project_%s');
Doctrine_Manager::getInstance()->setAttribute(Doctrine::ATTR_VALIDATE, Doctrine::VALIDATE_ALL);
Doctrine_Manager::getInstance()->setAttribute(Doctrine::ATTR_QUOTE_IDENTIFIER, true);
Doctrine::loadModels('models/generated');
Doctrine::loadModels('models');

$cli = new Doctrine_Cli(array(
'data_fixtures_path' => dirname(_FILE_).DIRECTORY_SEPARATOR.'fixtures',
'models_path' => dirname(_FILE_).DIRECTORY_SEPARATOR.'models',
'migrations_path' => dirname(_FILE_).DIRECTORY_SEPARATOR.'migrations',
'sql_path' => dirname(_FILE_).DIRECTORY_SEPARATOR.'sql',
'yaml_schema_path' => dirname(_FILE_).DIRECTORY_SEPARATOR.'schema'
));

$cli->run($_SERVER['argv']);

I find this very weird because earlier today I was able to make a migration the same way but with Symfony's CLI, however, that is another project.

Regards,

David

I've found an issue where doctrine will use the wrong connection for tables under certain conditions.

In a template, I'm doing a $sf_user->hasCredential() - which is causing this to be run in sfGuardSecurityUser,

$this->user = Doctrine::getTable('sfGuardUser')->find($id);

When this execute, the calls find themselves to Doctrine_Manager::getConnectionForComponent($componentName)

This method calls Doctrine_Core::modelsAutoload($componentName);, which fails to load the class, and returns false (no checking is done to see if it should return true).

As this fails to include the sfGuardUser classes wher the component binding goes on, the getTAble call will use the default connection, then create the table fails to use the correct connection

Doctrine_Core::getTable()

return Doctrine_Manager::getInstance()->getConnectionForComponent($componentName)->getTable($componentName);

the binding is done after the call to getConectionForComponent, as it's getTable that will ultimately cause the autoloader to pull in the table classes.

When defining languages as language_COUNTRY codes (supported by symfony by default), the functionality to work with I18n records breaks, resulting in "SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry" errors.

The reason is very simple: Doctrine's I18n language column is defined as a CHAR(2), thus shortening eg. "en_GB" value to "en", thus causing the above SQL error when a "en" translation for a record already exists.

The solution is even simpler: change the column's length to 7 in the Doctrine_I18n class's options: I've tested this and all runs great: the correct SQL is being generated, the models behave correct, ...

Once the upgrade was done from Doctrine 1.2.1 to 1.2.2 we discovered that date related issues started to appear.
With dates that are persisted in DB as NULL are translated to "0000-00-00" when retrieved from DB. This has occurred in multiple places and is quite worrying as there is a lot of dates in our project. This means that everywhere in our codebase where we check a datevalue in our Models is NULL we need also to check for the string literal "0000-00-00".

With a object that is created via a save(), and the record's primary key is a INT fed by a SEQUENCE, the type of the variable is an INT.

With an object that is hydrated from the database via a SELECT, the record's primary key INT will come back in 'toArray()' as a STRING.

That means that checking for type has to know what context it came from, user, INSERT, or SELECT. Not fun.

This also screws up converting arrays to JSON, 'cause the STRINGS get quotation marks and the INTS do not.

As a general rule, everything FROM the database seems to be strings. Yes, I know, everything 'on the wire' or 'through a socket' comes out as text. And it's a lot faster to leave it that way.

But having the type be different depending on the database operation? Not sure I like that.

I have a migration that adds constraints correctly. When migrating down, however, I get a syntax error

  Error #1 - 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 'CONSTRAINT unique_username_idx' at line 1. Failing Query: "ALTER TABLE conUser DROP CONSTRAINT unique_username_idx"

Here is the down migration:

    public function down() {
        $this->dropConstraint('conUser', 'unique_username_idx');
    }

The SQL generated is "ALTER TABLE conUser DROP CONSTRAINT unique_username_idx". This post (http://forums.mysql.com/read.php?98,70887,70974#msg-70974) suggests that in MySQL the syntax should be "ALTER TABLE conUser DROP INDEX unique_username_idx" as constraints are basically indexes in MySQL (unlike MSSQL and Oracle). Doctrine's lib/Doctrine/Export/MySql.php appears to have a syntax error in the dropConstraint method. I attach a patch for this, but the only change is replacing "$name = 'CONSTRAINT '" with "$name = 'INDEX '" in dropConstraint. The migration then runs as I would expect.

Sorry if this has been fixed elsewhere, I did a search but couldn't find a similar ticket.

When Doctrine_Query::parseFunctionExpression() is called with the following parameter and $this->_conn->expression is of type Doctrine_Expression_MySql:

$expr = "DATE_FORMAT(datefield,'%Y-%m-%d'),someotherfield"

The expected result from Doctrine_Query::parseFunctionExpressoin() would be

DATE_FORMAT(l.datefield,'%Y-%m-%d'),l.someotherfield

However, the actual result is

DATE_FORMAT(l.datefield,'%Y-%m-%d'),someotherfiel

Note the missing leading "l." and the last character ("d") on "someotherfield".
Obviously this leads to fatal errors.

This example is a result of calling addGroupby("DATE_FORMAT(datefield,'%Y-%m-%d'),someotherfield") on a Doctrine_Query object.

I reported this bug on the symfony site, but after investigation i have found that it is actually a doctrine SoftDelete issue. http://trac.symfony-project.org/ticket/8898

I have a sandbox replicating the problem here:
http://dl.dropbox.com/u/8354765/sf_sandbox.zip

Run the test:
./symfony test:unit Contact

The issue is I want to hard delete my M-M link table and soft delete the parents. This fails. I believe it is to do with the fact that the relations to the parent are marked as Doctrine_Record::STATE_TCLEAN which when the SoftDelete calls save on the parent object this flag trys to reinsert the relations that it has deleted. Things go very wrong at this point and the connection is rolled back.

The fix I have is the following, not sure what this would do to other things or not as I am not overly familiar with Doctrine internals...

Index: Doctrine/Template/Listener/SoftDelete.php
===================================================================
--- Doctrine/Template/Listener/SoftDelete.php	(revision 12962)
+++ Doctrine/Template/Listener/SoftDelete.php	(working copy)
@@ -95,6 +95,7 @@
     public function postDelete(Doctrine_Event $event)
     {
         if ( ! $this->_options['hardDelete']) {
+            $event->getInvoker()->clearRelated();
             $event->getInvoker()->save();
         }
     }

This works even if the relations have been marked as SoftDelete.

If you define a primary column, the attribute notnull is removed from the column definition because Doctrine assumes that primary columns are always not null.

Now suppose you have a schema like this, with a string primary column.

Client:
  columns:
    serial:    { type: string(50), notnull: true, primary: true }
    name:      { type: string(36), notnull: true }

That's fine, but causes problems with MySQL where the column is created with a default value of "" (empty string) and not <none>.

CREATE TABLE client (serial VARCHAR(50), name VARCHAR(36) NOT NULL, PRIMARY KEY(serial)) ENGINE = INNODB;

Note that the 2nd column is well defined and has <none> as default value (as seen from phpMyAdmin).

I attached a quick-workaround to disable the code which removes the notnull attribute from column definition.

After that the SQL code is like this:

CREATE TABLE client (serial VARCHAR(50) NOT NULL, name VARCHAR(36) NOT NULL, PRIMARY KEY(serial)) ENGINE = INNODB;

In the ERD/schema that I have set up, a couple levels down in hierarchal order, a table has 3 composite foreign keys, and one sequence of its own. That sequence does not get get set into the 'Table->sequence variable'. That means when the file 'UnitOfWork' executes the function '_assignSequence()', it finds no sequence name, and skips the assignment of the sequence value.

This of course blows up my inserts.

I have included the following documentation:

A/ An installation and further description README.tx file.
B/ SQL script to generate a anonymous version of my ERD - I.E. the table names and column names have been changed to protect the guilty (and proprietary)
C/ A fixture file to load some data.
D/ A *.png file showing a graphical view of the ERD.
E/ The generated schema.yml file from ./symfony doctrine:build-schema
F/ A modifiled (has certain echo statements for troubleshooting purposes) UnitOfWork.php file.
G/ A task file to run that tries to load the schema with valid values.
H/ An output file from running the Task and modified UnitOfWork.php file showing the exact point of error during insert.

Please let me know what I can do to help get this troubleshot quicly. Thx
E/

To validate data of type 'timestamp', the validator splits the Date/Time using a space, where as, the format created by date('c') specifies a 'T' to split the Date/Time. It seems the simple fix should be to change the space on line 47 of Doctrine/Validator/Timestamp.php to a 'T'

Date generated from gmdate('c') - 2010-03-02T22:08:56+00:00

If a record does not have any values set, but its identifier is defined as autoincrement, the record cannot be inserted into PostgreSQL.

In Doctrine_Connection_UnitOfWork::processSingleInsert():

 
       $fields = $record->getPrepared();
        $table = $record->getTable();

       // Populate fields with a blank array so that a blank records can be inserted
        if (empty($fields)) {
            foreach ($table->getFieldNames() as $field) {
                $fields[$field] = null;
            }
        }

This code snippet will add null values to all fields, including to the autoincrement identifier.
Then later in Doctrine_Connection_Pgsql::insert():

       // fix #1786 and #2327 (default values when table is just 'id' as PK)
        if(count($fields) === 1 && $table->isIdentifier(key($fields)) && $table->isIdentifierAutoincrement() )
        {
            return $this->exec('INSERT INTO ' . $this->quoteIdentifier($tableName)
                              . ' '
                              . ' VALUES (DEFAULT)');
        }

        foreach ($fields as $fieldName => $value) {
            $cols[] = $this->quoteIdentifier($table->getColumnName($fieldName));
            if ($value instanceof Doctrine_Expression) {
                $a[] = $value->getSql();
                unset($fields[$fieldName]);
            } else {
                $a[] = '?';
            }
        }

The claimed fix for the referenced tickets does not work correctly for 2 reasons:
1. It only works for tables with a single id field
2. It only works correctly if the id field had no value assigned. If there was a value assigned, it silently bypasses it, and inserts with the autoincremented value.

Patch with test case will be attached to the ticket.

References:
http://trac.doctrine-project.org/ticket/2327
http://trac.doctrine-project.org/ticket/1786

I don't know if this is important but it seems sfYaml is included twice in Doctrine 1.2.1. Once in vendor/sfYaml and once again in Doctrine/Parser/sfYaml

When generating models from db with doctrine 1.2.2, default with functions in database get evaluated and the value goes to the generated schema files thus cousing error on insert/update.

Example:
Table:
CREATE TABLE Usuario (
id SERIAL NOT NULL,
apelido CHARACTER VARYING(50) NOT NULL,
email CHARACTER VARYING(255) NOT NULL,
dtRegistro TIMESTAMP DEFAULT 'now()' NOT NULL,
idUsuarioSituacao INTEGER,
senha CHARACTER(32),
CONSTRAINT PK_Usuario PRIMARY KEY (id),
CONSTRAINT TUC_Usuario_1 UNIQUE (email)
)

Code to generate files:
$dManager = Doctrine_Manager::getInstance();
$dManager->setAttribute(Doctrine::ATTR_MODEL_LOADING,Doctrine::MODEL_LOADING_CONSERVATIVE);
$dManager->setAttribute(Doctrine_Core::ATTR_MODEL_LOADING, Doctrine_Core::MODEL_LOADING_CONSERVATIVE);

$dManager->setAttribute(Doctrine::ATTR_PORTABILITY, Doctrine::PORTABILITY_NONE);
$dManager->setAttribute(Doctrine::ATTR_VALIDATE, Doctrine::VALIDATE_NONE);
$dManager->setAttribute(Doctrine::ATTR_AUTO_ACCESSOR_OVERRIDE, true);
$dManager->setAttribute(Doctrine::ATTR_AUTOLOAD_TABLE_CLASSES, true);
$dManager->setAttribute(Doctrine::ATTR_QUERY_LIMIT, Doctrine::LIMIT_ROWS);

Doctrine_Core::generateModelsFromDb('c:\temp', array('dbcon'), array('generateTableClasses' => true, 'classPrefix' => 'D'));

Resulting file:
abstract class DBaseUsuario extends Doctrine_Record
{
public function setTableDefinition()

}

The function now() for default value gets replaced by 'default' => '\'2010-06-04 11:10:12.078\'::timestamp without time zone',

When I try to execute a migration of my DB with doctrine CLI migrate, i get this error.
I fixed it changing the following in Export/Oracle.php
#501 : $fields[] = $this->conn->getDeclaration($fieldName, $field); => $fields[] = $this->getDeclaration($fieldName, $field);

#509 : $fields[] = $fieldName. ' ' . $this->conn->getDeclaration('', $field['definition']); => $fields[] = $fieldName. ' ' . $this->getDeclaration('', $field['definition']);

Im have setup search behaviour for my model.

Searching phrase "foo bar" throws "Doctrine_Connection_Mysql_Exception"

SQLSTATE[21000]: Cardinality violation: 1242 Subquery returns more than 1 row

To fix the issue replace line 208 in file: Doctrine/Search/Query.php

$where .= ' AND (position + ' . $k . ') = (SELECT position FROM ' . $this->_table->getTableName() . ' WHERE ' . $this->parseWord($word) . ')';

with:

$where .= ' AND (position + ' . $k . ') IN (SELECT position FROM ' . $this->_table->getTableName() . ' WHERE ' . $this->parseWord($word) . ')';

importSchema in Doctrine_Import(l:369) iterates over the connections to check if it matches the passed $databases, however, giving the connection a name anything different than the databasename causes the entire function to malfunction..

So a workaround is to pass connection names as a second argument to `generateModelsFromDb` instead of the database names.

Also, if you wouldnt give a name to a connection, as you would possible do with cache connections since the argument isnt mandatory, then the equation is skipped entirely causing it to run on the cache connection..

In Record.php, _get() method called with $load parameter setted to false can generate an E_NOTICE.
Attached patch fix this.

When building base models on multiple boxes with different operating systems, the use of PHP_EOL in the model builder is problematic since when you rebuild you basically change every line of every file, leading to huge commits that are impossible to review.

I therefore added an eolStyle option to the Doctrine_Import_Builder class that allows you to specify which EOL markers to use.

It works perfectly fine here and the patch is attached, if the option is not specified the code remains the same as before btw so no performance loss or any possible BC break.

Thanks

http://trac.symfony-project.org/ticket/8421

It seems like it just requires to pass in a builderOption array into any class extending Doctrine_Record_Generator. I think it would be a good idea to start adding support for this into all internal behaviors.

and then doing something like the following in the schema:

Foo:
actAs:
Taggable:
builderOptions:
baseClassName: MyBaseRecord

call that fails is Doctrine::getTable('Building')->find(1). With mysql all is fine, but if I use MSSQL via odbc (SQL Native Client) I get an exception saying:
SQLSTATE[22018]: Invalid character value for cast specification: 206 [Microsoft][SQL Native Client][SQL Server]Er is een conflict met het type operand ontstaan: text is incompatibel met int (SQLExecute[206] at ext\pdo_odbc\odbc_stmt.c:254)
see attached stacktrace.
So find(1) fails but a call to e.g. findAll() works fine.

I found out that if I leave out the limit(1) from the function find() on line 1602 it gives me the correct object and no exception!
So actually what goes wrong is the limit(1) clause in this call:
$object = Doctrine_Query::create()>from('Building b')>where('b.id = 1')>limit(1)>fetchOne();
with getSqlquery() this becomes:
SELECT TOP 1 [inner_tbl].[id] AS [b__id] FROM (SELECT TOP 1 [b].[id] AS [b__id], [b].[version] AS [b__version], [b].[name] AS [b__name], [b].[number] AS [b__number], [b].[title_nl] AS [b__title_nl], [b].[title_en] AS [b__title_en], [b].[published] AS [b__published] FROM [building] [b] WHERE ([b].[id] = ?)) AS [inner_tbl]

If executed with sqlcmd.exe this gives an error saying 'no columnname id', what seems to be correct since it should be [inner_tbl].[b__id] iso [inner_table].[id], so I suspect that the modifyLimitQuery() function in Connection/Mssql.php is not correct either.

I can work around this problem by doing a fetchOne() iso find().

The Sluggable template does not add an index for the slug if the fields option is empty.

The provider option will not be used if the fields option is not empty.

The Sluggable template does not use the fields option in creating the index for the slug, so removing the requirement for a non-empty fields option seems to be an appropriate fix.

When using PearStyle model loading and a classPrefix, the Doctrine CLI will ignore any SQL operations if model_autoloading is set to conservative . If model_autoloading is set to aggressive, then everything works as expected.

Here's my Doctrine configuration:

doctrine.generate_models_options.pearStyle = true
doctrine.generate_models_options.generateTableClasses = false
doctrine.generate_models_options.generateBaseClasses = true
doctrine.generate_models_options.baseClassPrefix = "Base_"
doctrine.generate_models_options.baseClassesDirectory =
doctrine.generate_models_options.classPrefixFiles = false
doctrine.generate_models_options.classPrefix = "Model_"
; Conservative Model Loading:
doctrine.model_autoloading = 2

and my Doctrine initialization method:
protected function _initDoctrine()

and my doctrine.php CLI file:

require_once 'Zend/Application.php';

// Create application, bootstrap, and run
$application = new Zend_Application(
APPLICATION_ENV,
APPLICATION_PATH . '/configs/application.ini'
);

$application->getBootstrap()->bootstrap('doctrine');

$config = $application->getOption('doctrine');
$cli = new Doctrine_Cli($config);
$cli->run($_SERVER['argv']);

As far as I can see, all rows are fetched from a view. There is not much sense to use views if you cannot filter result based on some where conditions, so this would be a great improvement to the View class.

Doctrine_Inflector::unaccent does not know about the norwegian accent characters æøåÆØÅ so when sluggable is making slugs it ends up splitting words

"Møte" is turned into 'm-te' instead of 'mote' which is more apropriate

in Doctrine/Sequence/Mssql.php the function lastInsertId() fails to retrieve the last inserted ID when inserting a record. Because the major release of my sql server is bigger than 8, it chooses $query = 'select SCOPY_IDENTITY()' which does not return a number (in fact it does not return anything), although the record IS inserted succesfully. The backtrace is attached.
If, on the other hand, I force doctrine to use 'select @@IDENTITY' the query does return the correct number and everything goes fine!
So I think the conditions which query to choose is incorrect. I tried both queries in SQL server itself and both queries returned the right number. But one of them gets lost somewhere when using it in doctrine.

I have a project name that contains an underscore. When I run the doctrine CLI to create the models from the yaml file, something string replaces all underscores with slashes.

So where I would be expecting the models to be generated in 'my_project/application/models', it is instead being generated in 'my/project/application/models'

It's a very minor problem I know that. However when I try to use getAccessors() or getMutators() functions, if nothing is set on the table definitions, it throws some notices on the php (on error_reporting all) that such an index does not exists. As there is no such index to be found it returns null instead of expected array (empty if there is no mutators for that table)

public function getAccessors()
{
$componentName = $this->_table->getComponentName();
if (!isset(self::$_customAccessors[$componentName]))

return self::$_customAccessors[$componentName];
}

such a code solves the problem and not notices is thrown and empty array is returned if there is no accessors. Same kind of an improvement is required for getMutators too

I know that this is a minor issue however I wanted to inform you.

Calling a query that doesn't use all tablecols gives php warnings such as:

Errorcode: E_WARNING [php warning] (2)
Message: Invalid argument supplied for foreach()
File: Record.php
Line: 1151

--------------------------------------------------------------
$data = empty($data) ? $this->getTable()->find($id, Doctrine_Core::HYDRATE_ARRAY) : $data;
foreach ($data as $field => $value) {
--------------------------------------------------------------

$data is empty but not an array.

@return docs of getSqlQueryPart should be mixed.
@return docs of setSqlQueryPart, addSqlQueryPart, removeSqlQueryPart, removeDqlQueryPart, copySubqueryInfo, useResultCache, useQueryCache, expireResultCache, expireQueryCache, setResultCacheLifeSpan and setQueryCacheLifeSpan should be Doctrine_Query.

This issue is also reported in the user ml. http://groups.google.com/group/doctrine-user/browse_thread/thread/ee5d40f03242af8b

Cannot parse table name including 'join'.

$q = new Doctrine_Query();
$q->from('MyJoinProblem');

In above code, I want to query like 'SELECT m.id AS m__id FROM MyJoinProplem m'.
But, Doctrine try to find 'My' table and 'Problem' table.
Table name is 'MyJoinProblem'.

Hello,
I'm using Symfony 1.4.1 with Doctrine (I imagine that the doctrine's version is 1.2.1), and I have a strange behavior because my table name is "piece_jointe", so it contains "JOIN" keyword inside.
In Doctrine_Query_Tokenizer class, the method bracketExplode explode string with a regular expression "#(JOIN)#i", so the table name is exploded and nothing works after that.

do you think it's possible to write a better regular expression to avoid this behavior ? Maybe add spaces after JOIN : "#(JOIN )#i but if there is a line break... or "#(JOIN[\s \n])#i"
For now, I'll rename the table !

Thanks a lot,
best regards
Etienne

Each Doctrine_Cache_Db->_doFetch() invocation costs about 50 ms on my PC(depending on the data of course). By using built-in pack() function performance can be increased 700x times. Each invocation now costs about 0.07 ms. The change is very considerable for pages with multiple queries.

I'm using the symfony framework but assume that the following only affects the classes that were auto generated by Doctrine.

When doctrine generates the model classes for e.g. the sql table "manage_users" it generates:

 
  lib/model/doctrine/ManageUsers.class.php                           <- extends Doctrine_Table
  lib/model/doctrine/ManageUsersTable.class.php                 <- extends BaseManageUsers
  lib/model/doctrine/base/BaseManageUsers.class.php       <- extends sfDoctrineRecord

As far as I understand the ManageUsersTable class is supposed to be autoloaded by Doctrine (cf. ATTR_AUTOLOAD_TABLE_CLASSES) and injected into
the class returned by Doctrine::getTable('ManageUsers').

The first problem is that it is hard to figure out for newbies how to access methods in this class because they try all means to instanciate it or looking for static methods but eventually fail

The second problem is that using it this way, the IDE auto completion feature has no chance to figure out that the returned object offers methods defined in ManageUsersTable.class.php, it can only know that the results is an instance of Doctrine_Table.

The third problem is that one has to repeatingly write Doctrine::getTable("ManageUser") in the source code which is quite error prone - or did you notice that I missed an "s" in the example just given The IDE has again no chance to spot this.

A simple solution to all problems would be an auto generated getInstance method like this:

 
 class ManageUsersTable extends Doctrine_Table {
    /** Returns an instance of this class.
     *
     * @return ManageUsersTable
     */
    public static function getInstance() {
        return Doctrine::getTable('ManageUsers');
    }
 }

This way one could write ManageUs<AUTOCOMPLETION>::getInstance()->get<AUTOCOMPLETION>(); and there would be far less typo bugs!

bye,

christian

grep -rn 'lenght' Doctrine/*
Doctrine/DataDict/Oracle.php:197: $lenght = 3;

MEDIUMINT error

} elseif ( ! is_null($length) && (int)$length <= 3) { // TINYINT
    $length = 1;
} elseif ( ! is_null($length) && (int)$length <= 5) { // SMALLINT
    $length = 2;
} elseif ( ! is_null($length) && (int)$length <= 8) { // MEDIUMINT
    $lenght = 3;
} elseif ( ! is_null($length) && (int)$length <= 10) { // INT
    $length = 4;
} elseif ( ! is_null($length) && (int)$length <= 20) { //BIGINT
    $length = 8;
}

After upgrading symfony from 1.2 to 1.4, my website began to have problems saving some models. After some research, I found that it was caused by infinite recursion. Let's say Model A has many B (B belongs to A). Each A also points to one of the B objects it owns. So it's a circular reference. Some ppl might argue that it's not a good pratice to have circular reference in the data model, I agree. But it worked fine in Doctrine 1.0, so I prefer not to change it. In Doctrine 1.2.1, it seems that when A and its related B are both modified (dirty), if I try to save A, Doctrine will try to save B due to cascade update, and when saving B, it will again try to save its related A ...

I compared the source code of Doctrine_Connection_UnitOfWork between 1.0 and 1.2.1, and found out that in Doctrine 1.2.1, the model is no longer locked when saveRelatedLocalKeys is invoked. I don't understand this change. After I changed the line "$this->saveRelatedLocalKeys($record);" to

$record->state($record->exists() ? Doctrine_Record::STATE_LOCKED : Doctrine_Record::STATE_TLOCKED);
$this->saveRelatedLocalKeys($record);
$record->state($state);

my website returned to normal again. And so far i haven't found any problem caused by my change

So I hope someone can look into this and let me know if my change is safe. Or if I'm wrong, is there any way I can get around the infinite recursion problem without changing my database schema? Thanks.

The solution was to allow Versionable to skip fields.
I've fixed with this changing:

Doctrine/AuditLog.php
#84:

$skipFields = (isset($this->_options['skipFields']))?$this->_options['skipFields']:array();

#88:

//inside the foreach
if(in_array($column, $skipFields))

Unknown macro: { continue; }

After that the Versionable will accept some parameters.

ps: If possible, let me know about this changes cause my sources are with this fix.

Generated by doctrine-cli SQL is:

– this is ok
CREATE TABLE "image" ("id" BIGSERIAL, "alt" VARCHAR(255), "title" VARCHAR(500), "filename" VARCHAR(255), "width" BIGINT, "height" BIGINT, "slug" VARCHAR(255), "createdat" TIMESTAMP NOT NULL, "updatedat" TIMESTAMP NOT NULL, PRIMARY KEY("id"));
CREATE TABLE "news" ("id" BIGSERIAL, "title" VARCHAR(255), "leadmarkup" VARCHAR(500), "leadhtml" VARCHAR(600), "bodymarkup" TEXT, "bodyhtml" TEXT, "slug" VARCHAR(255), "createdat" TIMESTAMP NOT NULL, "updatedat" TIMESTAMP NOT NULL, PRIMARY KEY("id"));
CREATE TABLE "snippet" ("id" BIGSERIAL, "name" VARCHAR(255), "bodymarkup" TEXT, "bodyhtml" TEXT, "slug" VARCHAR(255), "createdat" TIMESTAMP NOT NULL, "updatedat" TIMESTAMP NOT NULL, PRIMARY KEY("id"));
– this causes error
CREATE UNIQUE INDEX "sluggable" ON "image" ("slug");
CREATE UNIQUE INDEX "sluggable" ON "news" ("slug");
CREATE UNIQUE INDEX "sluggable" ON "snippet" ("slug");

After importing this to PostgreSQL, I get 'index already exists' error.

On PostgreSQL unique indexes names must not be the same.
I think the correct form should be:
CREATE UNIQUE INDEX "sluggable-image" ON "image" ("slug");
CREATE UNIQUE INDEX "sluggable-news" ON "news" ("slug");
CREATE UNIQUE INDEX "sluggable-snippet" ON "snippet" ("slug");

Schema file attached.

At this moment, if you have more than one table that is sluggable, it get an error cause tries to set the very same name to ALL sluggable indexes. Here is a fix:

#55: 'indexName' => null

#74: if($this->_options['indexName'] === null)
#75: $this->_options['indexName'] = $this->getTable()- >getTableName().'_sluggable';

All keys are being set as primary key, wich is useless once we have a serial.

Fix: Doctrine/I18n.php
#098: $defaultOptions = array(
#099: 'fixed' => true,
#100: 'primary' => false
#101: )

Add ability to cache result of Doctrine_Core::loadModels().
My "models" folder contains more than 20 record classes plus more than 20 base classes. I added result caching for conservative model loading and it's reduced application bootstrap time more than 100ms.
Here code that I added to Doctrine_Core::loadModels()
Cache hit check at the beginning of the method

                $models = zend_shm_cache_fetch('doctrine::models_conservative');
                $modelPatch = zend_shm_cache_fetch('doctrine::models_conservative_paths');
                if(false !== $models && false !== $modelPatch){
                    self::$_loadedModelFiles = $modelPatch;
                    return $models;
                }

Result caching before return data

           asort($loadedModels);
            zend_shm_cache_store('doctrine::models_conservative',$loadedModels);
            zend_shm_cache_store('doctrine::models_conservative_paths',self::$_loadedModelFiles);
            return $loadedModels;

Of course zend_shm_cache_* is not proposed as caching solution.
I didn't use agressive model loading, but I think that caching for aggresive modlel loading can be done with compilation of all models to one file

Doctrine_Core::autoload around line 1107
if (strpos($className, 'sfYaml') === 0 || class_exists($className, false)) {

should be changed to

if (strpos($className, 'sfYaml') === 0) {

otherwise you get:
Warning: require(/srv/www/pacs.lan/site/lib/Doctrine/Parser/sfYaml/Doctrine_Query_From.php) [function.require]: failed to open stream: No such file or directory in /srv/www/pacs.lan/site/lib/Doctrine/Core.php on line 1108

Fatal error: require() [function.require]: Failed opening required '/srv/www/pacs.lan/site/lib/Doctrine/Parser/sfYaml/Doctrine_Query_From.php' (include_path='/srv/www/pacs.lan/site/lib/:/srv/www/pacs.lan/site/lib/Dwoo/:.:/usr/local/lib/php') in /srv/www/pacs.lan/site/lib/Doctrine/Core.php on line 1108

Dears,

Let's say you create your database first. If you have a serial/bigserial, a sequence is automaticaly created. It's called for example: 'id_seq'
During the cretion of the model, the sequence name is, so, called id_seq.

But in Doctrine_Formatter, line 233, you have getSequenceName that format Doctrine_Core::ATTR_SEQNAME_FORMAT that comes from Doctrine_Manager line 143, you have Doctrine_Core::ATTR_SEQNAME_FORMAT => "%s_seq", so, the sequence name will wrongly be id_seq_seq.

This could be avoid if the sequence_name would not contain the "_seq" suffix coming from the import. WDYT?

This could be possible thanks to a change in Doctrine_Import_Pgsql, line 50:

'listSequences' => "SELECT
        rtrim(relname, '_seq')
    FROM
        pg_class
    WHERE relkind = 'S' AND relnamespace IN
        (SELECT oid FROM pg_namespace
        WHERE nspname NOT LIKE 'pg_%' AND nspname != 'information_schema')",

So, rtrim(relname, '_seq') in place of relname only.
I'm not sure rtrim is the best solution but you got what I meant.

Voilà my 2 cents.

Hope it will help

Best regards,

Raphaël Dehousse

There are some typos in your documentation for Taggable extension.

In section related to getPopularTags method, if I use your code, like Doctrine::getTable('BlogPost')->getPopularTags(); I get an exception "Unknown method Doctrine_Table::getPopularTags" (with replacing BlogPost by my model name). In effect, it's not the table for my model that I must use but the table for TaggeableTag.
Besides, in your tests, you use Doctrine::getTable('TaggableTag')

I have write a patch to fix these typos. It's attached to this ticket.

Dears,

First, I would like to thank you for your great work.

Second, the bug:

Line ~279 in the function listTableRelations, there is a mistake in the use of strpos : strpos(',', $values[1]) and strpos(',', $values[3]), it should be strpos($values[1], ',') and strpos($values[2], ',')

With this code, strpos always returns false and so, the composite foreign keys are not skipped as desired.

Continue your great job

Regards,

Raphaël Dehousse

I noticed that the TaggableTag class does not contain a __toString() method. Looking further I found that the generator does not support this atm, but it was easy to add.

Can not use charset and collate in a table basis when using global charset and collate in Doctrine_Manager.

When using + symfony:

public function configureDoctrine(Doctrine_Manager $manager)
  {
    $manager->setCharset('utf8');
    $manager->setCollate('utf8_bin');
  }

And some schema like,

PageIndex:
  tableName:                           t_page_index
  columns:
    id:                                { type: integer  , length: 20 , primary: true    , autoincrement: true                                                  }
    title:                             { type: string   , length: 200                   , notnull: true                                                        }
  options:
    collate:                           utf8_general_ci
    

When generating the database, the table will have as collate utf8_bin, not being possible overwriting it at a table level.

This is because:

public function __construct($name, Doctrine_Connection $conn, $initDefinition = false)
    {
        $this->_conn = $conn;
        $this->_options['name'] = $name;
        
        $this->setParent($this->_conn);           
        $this->_conn->addTable($this);
        
        $this->_parser = new Doctrine_Relation_Parser($this);
        
        if ($initDefinition) {
            $this->record = $this->initDefinition();

            $this->initIdentifier();

            $this->record->setUp();

            // if tree, set up tree
            if ($this->isTree()) {
                $this->getTree()->setUp();
            }
        } else {
            if ( ! isset($this->_options['tableName'])) {
                $this->setTableName(Doctrine_Inflector::tableize($this->_options['name']));
            }
        }
        
        $this->_filters[]  = new Doctrine_Record_Filter_Standard();
        $this->_repository = new Doctrine_Table_Repository($this);

        if ($charset = $this->getAttribute(Doctrine_Core::ATTR_DEFAULT_TABLE_CHARSET)) {
            $this->_options['charset'] = $charset;
        }
        if ($collate = $this->getAttribute(Doctrine_Core::ATTR_DEFAULT_TABLE_COLLATE)) {
            $this->_options['collate'] = $collate;
        }

        $this->construct();
    }

Here the charset and the collate are overwritten (in the last lines of the method) by the global values.

A fix could be something like:

public function __construct($name, Doctrine_Connection $conn, $initDefinition = false)
    {
        $this->_conn = $conn;
        $this->_options['name'] = $name;
        
        $this->setParent($this->_conn);           
        $this->_conn->addTable($this);
        
        $this->_parser = new Doctrine_Relation_Parser($this);
        

        if ($charset = $this->getAttribute(Doctrine_Core::ATTR_DEFAULT_TABLE_CHARSET)) {
            $this->_options['charset'] = $charset;
        }
        if ($collate = $this->getAttribute(Doctrine_Core::ATTR_DEFAULT_TABLE_COLLATE)) {
            $this->_options['collate'] = $collate;
        }

        if ($initDefinition) {
            $this->record = $this->initDefinition();

            $this->initIdentifier();

            $this->record->setUp();

            // if tree, set up tree
            if ($this->isTree()) {
                $this->getTree()->setUp();
            }
        } else {
            if ( ! isset($this->_options['tableName'])) {
                $this->setTableName(Doctrine_Inflector::tableize($this->_options['name']));
            }
        }
        
        $this->_filters[]  = new Doctrine_Record_Filter_Standard();
        $this->_repository = new Doctrine_Table_Repository($this);

        

        $this->construct();
    }

Now the initDefinition method is called after the setup of the global charset and collate. Then if found a collate option in the table then that collate will be used.

When using the result of a:

$q = Doctrine::createQuery()
        ->from('User u')
        ->leftJoin('Role r');

$users = $q->execute();

now if we want to iterate and know if exists the according role for each user

foreach ($users as $user)
{
  $role_name = $user->relatedExists('Role') ? $user->getRole()->getName() : '';
}

the exception in the relatedExists method will be thrown:

public function relatedExists($name)
    {
        $newReference = false;
        if ( ! $this->hasReference($name)) {
            $newReference = true;
        }

        $reference = $this->$name;
        if ( ! $reference instanceof Doctrine_Record) {
            throw new Doctrine_Record_Exception(
                'You can only call relatedExists() on a relationship that '.
                'returns an instance of Doctrine_Record'
            );
        }
        $exists = $reference->exists();

        if ($newReference) {
            $this->clearRelated($name);
        }

        return $exists;
    }

because the according role record does not exist for some users ( a user just could have one record).

it could be better this way:

public function relatedExists($name)
    {
        $newReference = false;
        if ( ! $this->hasReference($name)) {
            $newReference = true;
        }

        $reference = $this->$name;
        if ( ! $reference && ! $this->getTable()->hasRelation($name)) {
            throw new Doctrine_Record_Exception(
                'You can only call relatedExists() on a relationship that '.
                'returns an instance of Doctrine_Record'
            );
        }

        $exists = $reference ? $reference->exists() : false;

        if ($newReference) {
            $this->clearRelated($name);
        }

        return $exists;
    }

With this change, this method can be used to check newly created user objects or some retrieved from the db (left join with role) smoothly.

From what I understand, doctrine mostly stores integers as strings. To check whether an integer has been modified, the following code in Doctrine_Record is used:

    protected function _isValueModified($type, $old, $new)
    {
        if ($new instanceof Doctrine_Expression) {
            return true;
        }

        if ($type == 'boolean' && (is_bool($old) || is_numeric($old)) && (is_bool($new) || is_numeric($new)) && $old == $new) {
            return false;
        } else if (in_array($type, array('decimal', 'float')) && is_numeric($old) && is_numeric($new)) {
            return $old * 100 != $new * 100;
        } else if (in_array($type, array('integer', 'int')) && is_numeric($old) && is_numeric($new)) {
            return (int) $old !== (int) $new;  # <--- ********** THIS LINE CASTS STRING TO INT **********
        } else if ($type == 'timestamp' || $type == 'date') {
            return strtotime($old) !== strtotime($new);
        } else {
            return $old !== $new;
        }
    }

On the line indicated above an integer, stored as a string, is cast to a PHP integer data type, and compared with the existing value of the field currently stored in the database. For values that fall within the int type range, this works fine. However, when changing a value falling above the range, which on 32bit systems is 2147483647, to another value falling above the range, these casts cause the code to evaluate both as 2147483647 and hence the field is not added to the _IsModified() array, and the value is not updated.

Bearing in mind that validation to confirm whether these strings are in numeric format should already have occurred by this point in the process, is there any need to cast the strings at all? Thus, is the following a possible solution?

            return $old !== $new;

This seems to work fine for me in my limited trials although, admittedly, there may be some consequences about which I am not aware.

Note that this issue is not so evident on 64bit systems, where the upper limit is much higher.

When using the code:

    $parent = new Category();
    $parent->setName('Parent');
    $parent->save();
    Doctrine_Core::getTable('Category')->getTree()->createRoot($parent);
    
    $child = new Category();
    $child->setName('Child');
    $child->save();
    
    $child->getNode()->insertAsLastChildOf($parent);

Now it throws an exception with the message:

"Unknown component alias Category" from the Doctrine_Query_Abstract class, line 743.

Tracking down the problem, it seems that in the method shiftRlValues there was a problem:

    // shift left columns
        $componentName = $this->_tree->getBaseComponent();

        $qLeft  = Doctrine_Core::getTable($componentName)
            ->createQuery()
            ->update();

        $qRight = Doctrine_Core::getTable($componentName)
            ->createQuery()
            ->update();

        $qLeft = $qLeft->set($componentName . '.lft', $componentName.'.lft + ?', $delta)
                       ->where($componentName . '.lft >= ?', $first);
        $qLeft = $this->_tree->returnQueryWithRootId($qLeft, $rootId);

        $resultLeft = $qLeft->execute();
        
        // shift right columns
        $qRight = $qRight->set($componentName . '.rgt', $componentName.'.rgt + ?', $delta)
                         ->where($componentName . '.rgt >= ?', $first);

        $qRight = $this->_tree->returnQueryWithRootId($qRight, $rootId);

        $resultRight = $qRight->execute();

Making a comparison with the NestedSet class in the 1.0 series, realized that the update methods need the component name resulting in:

    // shift left columns
        $componentName = $this->_tree->getBaseComponent();

        $qLeft  = Doctrine_Core::getTable($componentName)
            ->createQuery()
            ->update(<b>$componentName</b>);

        $qRight = Doctrine_Core::getTable($componentName)
            ->createQuery()
            ->update(<b>$componentName</b>);

        $qLeft = $qLeft->set($componentName . '.lft', $componentName.'.lft + ?', $delta)
                       ->where($componentName . '.lft >= ?', $first);
        $qLeft = $this->_tree->returnQueryWithRootId($qLeft, $rootId);

        $resultLeft = $qLeft->execute();
        
        // shift right columns
        $qRight = $qRight->set($componentName . '.rgt', $componentName.'.rgt + ?', $delta)
                         ->where($componentName . '.rgt >= ?', $first);

        $qRight = $this->_tree->returnQueryWithRootId($qRight, $rootId);

        $resultRight = $qRight->execute();

Now the queries work correctly!.

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

I seems the cause of the problem was the fact of overwriting createQuery method from Doctrine_Table

  public function createQuery($alias = '')
  {
    $alias = empty($alias) ? $this->getAlias() : trim($alias);
    $alias = ' '.$alias;
    
    $class = $this->getAttribute(Doctrine_Core::ATTR_QUERY_CLASS);

    return Doctrine_Query::create(null, $class)->from($this->getComponentName().$alias);
  }
  public function getAlias()
  {
    $name  = substr(get_class($this), 0, -5);
    $name  = sfInflector::underscore($name);
    $names = explode('_', $name);
    array_walk($names, create_function('&$v, $k', '$v = $v{0};'));
    $alias = implode('', $names);
    
    return $alias;
  }

I was trying to give and alias always by default:

Category -> c
CategoryAttribute -> ca
CategoryAttributeExtension -> cae

This breaks shiftRlValues method from NestedSet because there, it is used the component name as alias, and when createQuery creates a "from" part with a different alias the whole query crush.

It would be nice to have this feature in a future release.

I found this ticket on the old Trac system, but not on JIRA. It is still broken in the 1.1 branch, as of revision 7004. It is also broken in 1.0.14, 1.1.6, and 1.2.1. (These were the 'stable' releases at the time I reported this bug.) It is likely broken in older releases as well.

When saving to the database, Doctrine ignores the setting of PORTABILITY_EMPTY_TO_NULL. Currently, it will never change empty strings to NULL, no matter what the setting is for ATRR_PORTABILITY. This is because there is an error in the following 'if' statement:

Doctrine_Connection_Statement starting on line: 234

if ($this->_conn->getAttribute(Doctrine::PORTABILITY_EMPTY_TO_NULL)) {
    foreach ($params as $key => $value) {
        if ($value == '') {
            $params[$key] = null;
        }
    }
}

the first test in this block should be (Portability Mode Attributes must be handled this way):

if ($this->_conn->getAttribute(Doctrine::ATTR_PORTABILITY) & Doctrine::PORTABILITY_EMPTY_TO_NULL) {

the second test should be:

if (is_string($value) && $value === '')

In newer versions of php(not sure which), test for empty string must look like '===' not only '=='. It prevents integer and boolean value 0 to be handled as an empty string.

The problem is in this method:

protected function _createMigrationTable()
{
    if ($this->_migrationTableCreated) {
        return true;
    }

    $this->_migrationTableCreated = true;

    try {
        $this->_connection->export->createTable($this->_migrationTableName, array('version' => array('type' => 'integer', 'size' => 11)));

        return true;
    } catch(Exception $e) {
        return false;
    }
}

When migration_version table doesn't exist, everything works like it should. But subsequent migrations fail, because after failing at creating migration_version table every subsequent queries in that transaction fail.

It works flawlessly with MySQL, but fails with PostgreSQL.