Hello,

I had a problem when i try to import data with an extended accessors when i try to insert a content with a relation. I discovered this problem in symfony.

For example, here is my table :

 
News:
  tableName: ne_news
  columns:
    id:           { type: integer(4), primary: true, autoincrement: true }
    author_id:    { type: integer(4), notnull: true }
    name:         { type: string(255) }
    description:  { type: text }
  relations:
    author: { class: sfGuardUser, onDelete: NULL, local: author_id, foreign: id, foreignAlias: sfGuardUser }

And the fixture :

 
SfGuardUser:
  sadmin:
    username:       admin
    password:       admin
    is_super_admin: true
  author1:
    username: myname
    
News:
  News1:
    name: Test 1
    description: Description of news 1
    author: author1

I import it with symfony doctrine:data-load and it works.

If i add a news.class.php and extends the autogenerated class it fails.

 
    public function setAuthor($v)
    {
        //__log('extending setter');
        return $this->_set('author', $v);
    }

WhenDoctrine_Data_Import finds the setAuthor function, it wont transform author1 in object so $v will be a string, not an sfGuardUser object.

What do you think? Is a common behavior, how can i extends my accessor?

If you set a setter method for a model which is for a relation the data import no longer works. This seems to be because in the _processRow method it checks if a method exists and then passes the default value rather than checking whether a relation exists first and passing the imported object.

This effectively means you can't overload a setter method and still use the data import.

Hi,

this issue was reported at the symfony project which uses Doctrine 1.2.3:
http://trac.symfony-project.org/ticket/9152
"php symfony doctrine:build-schema failure with PostgreSQL for 1.4.7 and 1.4.8 version"

The SQL Statement 'listTableColumns' fails with an SQL-Error "missing from-clause"
http://trac.doctrine-project.org/browser/tags/1.2.3/lib/Doctrine/Import/Pgsql.php#L96
I can reproduce the error directly in psql or pgadmin. The SQL Statement seems related to DC-697

Even when i turn on the add_missing_from option on the postgres-server it fails with "missing relation".

Now it seems to me, you already fixed this bug in the current 1.2 branch, because the current SQL-Statement is different and it works for me in psql/pgadmin.
http://trac.doctrine-project.org/browser/branches/1.2/lib/Doctrine/Import/Pgsql.php#L96

Could you please close this ticket, if you already fixed this issue, or confirm if it's still an issue?
Attached you find my proposed patch at the symfony project . the current statement in the branch looks too different from my version, so i am not sure to use this patch directly. Tell me if I should work out a proper patch.

SQLSTATE[42P01]: Undefined table: 7 ERROR:  missing FROM-clause entry for table "t"                                               
 	  LINE 6: ...                                                  t.typtype ...                                                       
 	                                                               ^. Failing Query: "SELECT                                           
 	                                                       ordinal_position as attnum,                                                 
 	                                                       column_name as field,                                                       
 	                                                       udt_name as type,                                                           
 	                                                       data_type as complete_type,                                                 
 	                                                       t.typtype AS typtype,                                                       
 	                                                       is_nullable as isnotnull,                                                   
 	                                                       column_default as default,                                                   
 	                                                       (                                                                           
 	                                                         SELECT 't'                                                                 
 	                                                           FROM pg_index, pg_attribute a, pg_class c, pg_type t                     
 	                                                           WHERE c.relname = table_name AND a.attname = column_name                 
 	                                                           AND a.attnum > 0 AND a.attrelid = c.oid AND a.atttypid = t.oid           
 	                                                           AND c.oid = pg_index.indrelid AND a.attnum = ANY (pg_index.indkey)       
 	                                                           AND pg_index.indisprimary = 't'                                         
 	                                                           AND format_type(a.atttypid, a.atttypmod) NOT LIKE 'information_schema%' 
 	                                                       ) as pri,                                                                   
 	                                                       character_maximum_length as length                                           
 	                                                     FROM information_schema.COLUMNS                                               
 	                                                     WHERE table_name = 'matable'                                   
 	                                                     ORDER BY ordinal_position"  

I use MySQL. In my up() method in migration class, I have:

$this->addColumn($table, 'is_master', 'boolean', null, array('notnull' => true, 'default' => false));

Running 'migrate' results in a following exception:
Error #1 - SQLSTATE[42000]: Syntax error or access violation: 1067 Invalid default value for 'is_master'. Failing Query: "ALTER TABLE books_authors ADD is_master TINYINT(1) DEFAULT '' NOT NULL"
#0 /usr/local/zend/share/pear/Doctrine/Connection.php(1025): Doctrine_Connection->rethrowException(Object(PDOException), Object(Doctrine_Connection_Mysql), 'ALTER TABLE boo...')
#1 /usr/local/zend/share/pear/Doctrine/Export.php(621): Doctrine_Connection->execute('ALTER TABLE boo...')
#2 /usr/local/zend/share/pear/Doctrine/Migration/Process.php(89): Doctrine_Export->alterTable('books_authors', Array)
#3 /usr/local/zend/share/pear/Doctrine/Migration.php(522): Doctrine_Migration_Process->processCreatedColumn(Array)
#4 /usr/local/zend/share/pear/Doctrine/Migration.php(479): Doctrine_Migration->_doMigrateStep('up', 1)
#5 /usr/local/zend/share/pear/Doctrine/Migration.php(328): Doctrine_Migration->_doMigrate(1)
#6 /usr/local/zend/share/pear/Doctrine/Core.php(1016): Doctrine_Migration->migrate(NULL)
#7 /usr/local/zend/share/pear/Doctrine/Task/Migrate.php(41): Doctrine_Core::migrate('/Users/argasek/...', NULL)
#8 /usr/local/zend/share/pear/Doctrine/Cli.php(516): Doctrine_Task_Migrate->execute()
#9 /usr/local/zend/share/pear/Doctrine/Cli.php(498): Doctrine_Cli->executeTask(Object(Doctrine_Task_Migrate), Array)
#10 /usr/local/zend/share/pear/Doctrine/Cli.php(452): Doctrine_Cli->_run(Array)
#11 /Users/argasek/Sites/blipoteka/scripts/doctrine-cli.php(28): Doctrine_Cli->run(Array)
#12

However, I would expect ALTER query to look like this:

ALTER TABLE books_authors ADD is_master TINYINT(1) DEFAULT 0 NOT NULL

I guess there's a problem with getDefaultFieldDeclaration() in Doctrine_Export_Mysql, it lacks convertBooleans() call being present at Doctrine_Export.

Hi,

There is maybe a typo. l. 194 in Doctrine/Import/Pgsql.php : typtype should be type?

Thanks

Hi

I recently encountered a problem when importing fixtures. I was ending up with invalid foreign key constraints due to the fact that the fixtures were importing in the wrong order. I tracked down the problem and figured out that the method Doctrine_Connection_UnitOfWork::buildFlushTree, while a truly impressive piece of sorting logic still some times still gets the order of the classes wrong in its end result.

I realized that all it needed though was a second shot at reordering the list – in other words it needed to exhaustively try to order the list until it found that everything was in the right order.

I put in a for loop in this method that will keep running until no order changes occurred or until a max number of attempts have been reached. The max number of attempts I added as a property of Doctrine_Connection called: maxBuildFlushTreeOrderAttempts.

This has solved my problem. I wouldn't be surprised if this was a common issue.

I will post my patch into this thread.

Hope all is well.

Will Ferrer

We recently made an extended version of Docrtine_Record which has some functionality that is specific to our project and we switched all our models to use this baseclass by setting the cli option: generate_models_options:baseClassName

We found that when we rebuilt our db this base class was being treated as it were a model (even though its an abstract class). This was causing some errors during our build and a table based on the name of the baseclass was being created.

I tracked the problem down to line 310 of Doctrine_Table where the do loop was only breaking for a class named "Doctrine_Record".

It seemed to make more sense to me to have this loop break for any abstract class, so I copied the technique used to check for abstract classes from Doctrine_Core Line 798. This broke a lot of tests however so due to time constraints I went with a simpler fix – instead I just changed the code that checks if the class is named "Doctrine_Record" to be a regular expression that checks to see if the class name starts with "Doctrine_Record" optionally followed by an underscore + more text in the class name.

This has fixed my issue and should let people make extensions of doctrine record which they can use as a baseclass provided that their class names indicate that they are extending Doctrine_Record.

The only problem I can see arising from this if some users have made models that they have named starting with "Doctrine_Record", but that seems like it would be an odd thing to do so this probably it won't be an issue.

I could however look more closely into detecting abstract classes if this would make my changes significantly more useful.

Please see attached patch.

Will Ferrer

This issue is exactly the same as DC-252, but refers to PostgreSQL

if you set prefix to "xyz_%s" and have the model "BackgroundColor" it will become the table => "xyz_background_color"
if you have the table "xyz_background_color" with unknown model and create the the model from the table, you will get => "XyzBackgroundColor".

The fix (diff):

368a369,370
> $tablePrefix = $manager->getAttribute(Doctrine_Core::ATTR_TBLNAME_FORMAT);
>
381d382
<
385c386
< $definition['className'] = Doctrine_Inflector::classify(Doctrine_Inflector::tableize($table));
—
> $definition['className'] = Doctrine_Inflector::classify(Doctrine_Inflector::tableize(preg_replace(sprintf('/\A%s\z/', str_replace('%s', '(.*?)', $tablePrefix)), '$1', $table)));
396c397
< $class = Doctrine_Inflector::classify(Doctrine_Inflector::tableize($table));
—
> $class = Doctrine_Inflector::classify(Doctrine_Inflector::tableize(preg_replace(sprintf('/\A%s\z/', str_replace('%s', '(.*?)', $tablePrefix)), '$1', $table)));

Sample schema:

Blog:
actAs: [Versionable, Searchable]
columns:
id:

name: string
text: text

When dumping data of a schema with Versionable and/or Searchable Behaviour, the dump.yml will contain all data, including the *_version and *_index tables.

Trying to load the same .yml file results in Duplicate-Key constraint violations, as long as the data for the *_version and *_index tables is present.
The import is only successfull, when the data for these tables is discarded.
This leads to the issue, that one can only do a dump-load cycle, when the complete version history of a Model is discarded. Which makes dump-load for such models rather useless.

I'm using doctrine and some of mysql's spatial functions. I need to specify spatial index for my tables.
My declaration looks like:

Geometry:
tableName: geometry
options:
type: MyISAM
collate: utf8_unicode_ci
charset: utf8
columns:
id:
type: integer(4)
primary: true
autoincrement: true
geometry:
type: geometry
notnull: true
indexes:
geometry:
fields:

• geometry
  type: spatial

Exporting this definitions throws an exception: Unknown type spatial for index geometry_idx

This bug was introduced by the person reporting the bug #DC-592.

When trying to generate an ALTER TABLE statement with Doctrine_Core::ATTR_QUOTE_IDENTIFIER enabled, the column identifier is not quoted, and a blank identifier is instead quoted, generating the following SQL:

ALTER TABLE "mytable" MODIFY (username "" VARCHAR2(200))

The proper SQL to be generated should be:

ALTER TABLE "mytable" MODIFY ("username" VARCHAR2(200))

Just like in Doctrine 2 (http://www.doctrine-project.org/jira/browse/DBAL-50):

The PostgreSQL database does not create indexes for foreign key columns, the user has to create them by hand. I think that indexes for foreign keys should be created automatically

Adding an invalid filename to the data-load task results in purging of all the data in the database.

I am attaching a patch that checks the loaded data if there were any values actually loaded from the fixtures.

While trying to load ~25M data fixtures (one big table with relations to 4 smaller ones, sfGuard included in that, row size around 500 bytes) in Symfony i ended up waiting around 80 minutes, while waiting i looked at what could have make it so dreadfully slow. Turns out, when Doctrine_Data_Load gets UnitOfWorks it executes save() on every new record. Save makes it's own transaction - not a problem if it's nested, but when this is the main transactions, 70000 of them make quite a difference. Remember - one of the main factors of DBMS speed is transactions/second.

I patched Doctrine_Data_Import to wrap everything in one transaction, and the results were great - from 80 minutes i got down to around 10. Still, not as fast as it should be but now it's usable. The time difference is notable also in smaller dumps.

Patch to speed up loading times included, would be great if you add it to trunk.

Please note - i have not checked this patch with any other setup or DBMS, please do so.

Also i have noticed something that might be a problem in much larger loads - if wrapping in a single transaction, my total memory usage went up for about 500M higher than in 70000 transactions. At some point, about 5 minutes in the process some kind of garbage collector fired and freed around 1 gig, so perhaps on larger dumps it might be a good idea to wrap the import not in one, but more transactions (like one transaction every 10000 operations).

If you create InnoDB tables from a given model directory, the table generator wants to create a foreign key constraint that already exists.

1. Doctrine_Core::generateModelsFromYaml('yaml', 'models');
2. Doctrine_Core::createTablesFromModels('models');
3. Running this setup twice, will print out the following error:

SQLSTATE[HY000]: General error: 1005 Can't create table './dev_mreiche/#sql-930_2cb7.frm' (errno: 121). Failing Query: "ALTER TABLE group_user ADD CONSTRAINT group_user_user_id_user_id FOREIGN KEY (user_id) REFERENCES user(id)". Failing Query: ALTER TABLE group_user ADD CONSTRAINT group_user_user_id_user_id FOREIGN KEY (user_id) REFERENCES user(id)

If I generate models from sql server I notice that the default values are empty although some columns in the database do have default values.

I did 'EXEC sp_columns @table_name = 'page';' in sql server and I could clearly see default values in 'column_def' so somehow the default values get lost.

The column type 'array' creates a column of the type 'LONGTEXT' but also adds the default value to the column declaration which makes the creation of the table fail.

MySQL does not support default values for TEXT, BLOB or LONGTEXT. I don't know when this behavior was added to MySQL or if it always has been like that. MySQL 5.0.51 will accept it without any SQL mode set, 5.0.83 won't.

When exporting my schema from yaml I noticed that some CONSTRAINT are not created, but all the models are. After analyzing the code I found that an issue is not related to YAML but is related to Doctrine_Table::getExportableFormat(). I have models creation option to create it in PEAR-like style.

So, when you have a schema like this:

----------------
Partner_Code:
tableName: partner_code
columns:
id:
type: integer(4)
unsigned: true
primary: true
autoincrement: true
notnull: true
code:
type: string(64)
unique: true
notnull: true

Partner_Channel:
tableName: partner_channel
columns:
id:
type: integer(4)
unsigned: true
primary: true
autoincrement: true
notnull: true
name:
type: string(64)
notnull: true
relations:
Codes:
class: Partner_Code
local: channel_id
foreign: code_id
refClass: Partner_Channel_Code
foreignAlias: Partner_Channel
foreignType: one
type: many

Partner_Channel_Code:
tableName: partner_channel_x_code
columns:
channel_id:
type: integer(4)
unsigned: true
primary: true
notnull: true
code_id:
type: integer(4)
unsigned: true
primary: true
notnull: true
----------------

it generates sql like this:

----------------
CREATE TABLE partner_channel (id INT UNSIGNED AUTO_INCREMENT, name VARCHAR(64) NOT NULL, PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci ENGINE = INNODB;
CREATE TABLE partner_channel_x_code (channel_id INT UNSIGNED, code_id INT UNSIGNED, PRIMARY KEY(channel_id, code_id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci ENGINE = INNODB;
CREATE TABLE partner_code (id INT UNSIGNED AUTO_INCREMENT, code VARCHAR(64) NOT NULL UNIQUE, PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci ENGINE = INNODB;
ALTER TABLE partner_channel_x_code ADD CONSTRAINT partner_channel_x_code_channel_id_partner_channel_id FOREIGN KEY (channel_id) REFERENCES partner_channel(id);
----------------

But should also generate:

----------------
ALTER TABLE partner_channel_x_code ADD CONSTRAINT partner_channel_x_code_code_id_partner_code_id FOREIGN KEY (code_id) REFERENCES partner_code(id);
----------------

But if I just change the schema with this changes (notice the Channel changed to Shannel):

----------------
Partner_Channel:
relations:
Codes:
refClass: Partner_Shannel_Code

Partner_Shannel_Code:
tableName: partner_channel_x_code
----------------

Everything is created.

----------------
CREATE TABLE partner_channel (id INT UNSIGNED AUTO_INCREMENT, name VARCHAR(64) NOT NULL, PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci ENGINE = INNODB;
CREATE TABLE partner_code (id INT UNSIGNED AUTO_INCREMENT, code VARCHAR(64) NOT NULL UNIQUE, PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci ENGINE = INNODB;
CREATE TABLE partner_channel_x_code (channel_id INT UNSIGNED, code_id INT UNSIGNED, PRIMARY KEY(channel_id, code_id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci ENGINE = INNODB;
ALTER TABLE partner_channel_x_code ADD CONSTRAINT partner_channel_x_code_code_id_partner_code_id FOREIGN KEY (code_id) REFERENCES partner_code(id);
ALTER TABLE partner_channel_x_code ADD CONSTRAINT partner_channel_x_code_channel_id_partner_channel_id FOREIGN KEY (channel_id) REFERENCES partner_channel(id);
----------------

So as I figured out is that when creating the tables alphabetic order has an influence on creating the CONSTRAINT for that Model in sql. I suppose line 715 of the Doctrine/Table.php near $key = $this->_checkForeignKeyExists(...) is operating, but I am not sure (when inserting into DB some tables are not created yet?).

Do not know how to markup here, it's my first issue in Jira, please press "edit" to see the yaml code formatted

With 1.2.2 we get errors for our generated PostgreSQL code: "sequence <sequence name> already exists". I tracked down the issue to the following:

Doctrine_Export_Pgsql::createTableSql() has the following new code:

        if (isset($options['sequenceName'])) {
            $sql[] = $this->createSequenceSql($options['sequenceName']);
        }

This is fine, but this CREATE SEQUENCE code is now added after the CREATE TABLE code. This does not work okay for PostgreSQL, since PostgreSQL will automatically create the index for you if it does not yet exist. If CREATE SEQUENCE is required for some reason, then it should ge before the CREATE TABLE to be useful (it could for example be useful if different increment intervals or starting numbers should be set for the sequence).

I tried moving the new code up, but that did not yet give me the desired results. The issue is that Doctrine_Export::exportClassesSql() collects all the SQL in an array and finally does:

rsort($sql);
return $sql;

This can break any statement set in there that should be run in a specific order. For the PostgreSQL code, this will put all the CREATE TABLE calls in font of the CREATE SEQUENCE calls, resulting in the errors that we see.

Suggested fix options:

1) Do not sort the SQL queries, but accept them as generated by the db specific Export class (but I'm only suggesting this, because I am not aware of the reason to do an rsort() in the first place).

2) Change the PostgreSQL export code to make it immune to the sorting.

We did the latter in our code. The CREATE SEQUENCE and CREATE TABLE are concatenated into one statement string ("<squence>;<table>") that is added to the list of SQL queries. This provides us a work-around for the problem. The first solution is more clean IMO, but I lack knowledge to tell if the rsort() is here for technical or aesthetic reasons.

it seems that the naming is important:

in a User, Group, UserGroup relation (where the UserGroup defines the many to many relation for User & Group) the constraints are defined well

but if the tables are Order, Service, OrderService it doesn't work => just one constraint is created... please find my example:

Order:
  tableName:          orders
  columns:
    name:             string(50)
  relations:
    Services:
      class:          Service
      local:          order_id
      foreign:        service_id
      refClass:       OrderService

Service:
  actAs:
    Versionable:      ~
  columns:
    name:             string(50)
  relations:
    Orders:
      class:          Order
      local:          service_id
      foreign:        order_id
      refClass:       OrderService

# WTF: it takes alphbetically the constraints building  !?
# if I used ZorderService instead of OrderService, Z is after S (O is before S) the constraints are defined fine!
OrderService:
  columns:
    order_id:         { type: integer, primary: true }
    service_id:       { type: integer, primary: true }

==> the generated SQL

CREATE TABLE orders (id BIGINT AUTO_INCREMENT, name VARCHAR(50), PRIMARY KEY(id)) ENGINE = INNODB;
CREATE TABLE order_service (order_id BIGINT, service_id BIGINT, version BIGINT, PRIMARY KEY(order_id, service_id, 
        version)) ENGINE = INNODB;
CREATE TABLE service_version (id BIGINT, name VARCHAR(50), version BIGINT, PRIMARY KEY(id, version)) ENGINE = 
        INNODB;
CREATE TABLE service (id BIGINT AUTO_INCREMENT, name VARCHAR(50), version BIGINT, PRIMARY KEY(id)) ENGINE = 
        INNODB;
ALTER TABLE order_service ADD CONSTRAINT order_service_order_id_orders_id FOREIGN KEY (order_id) REFERENCES 
        orders(id);
ALTER TABLE service_version ADD CONSTRAINT service_version_id_service_id FOREIGN KEY (id) REFERENCES service(id) 
        ON UPDATE CASCADE ON DELETE CASCADE;

=> as you can see for TABLE order_service just one constraint is defined (order_service_order_id_orders_id) the other one (order_service_service_id_service_id) is missing !!!

However if i change the names for tables (actually i think alphabetically order) and use ZorderService instead of OrderService (lik UserGroup for User & Group) the two constraints are created!

This also affects the "getRelations()" when i tried to write a behavior (it gives back just one relation):

  foreach ($event->getInvoker()->getTable()->getRelations() as $relation)

ps:
also the same bug reported on the list: http://groups.google.com/group/doctrine-user/browse_thread/thread/ad48db71b71e043b

_{(edit G.X: split too long lines in SQL code)}

While playing with createIndexSql() and dropIndexSql() i noticed, that the pgsql implementation differs from mysql. The index names usually are build with a '_idx' after the name. This is done through the formatter, i guess.

I noticed, that in Doctrine_Export class the createIndexSql() method does not use the formatter, while dropIndexSql() do. So creating and dropping indexes on pgsql (in my case) fails because of the different names. It does work on mysql, because Doctrine_Export_Mysql class uses it's own createIndexSql() method where the formatter is used.

Michael

There's a problem with Doctrine_Data_Import. When trying to load a fixture record with translations, and GoogleI18n (or similar) instead of I18n is used (via actAs()), the following crash happens:
Couldn't create collection index. Record field 'lang' was null.

#0 /Users/argasek/Sites/fwm/library/doctrine/Doctrine/Access.php(131): Doctrine_Collection->add(Object(Fwm_Shop_Catalog_CategoryTranslation))
#1 /Users/argasek/Sites/test/library/doctrine/Doctrine/Data/Import.php(241): Doctrine_Access->offsetSet(NULL, Object(Test_Shop_Catalog_CategoryTranslation))
#2 /Users/argasek/Sites/test/library/doctrine/Doctrine/Data/Import.php(335): Doctrine_Data_Import->_processRow('(catalog_catego...', Array)
#3 /Users/argasek/Sites/test/library/doctrine/Doctrine/Data/Import.php(118): Doctrine_Data_Import->_loadData(Array)
#4 /Users/argasek/Sites/test/library/doctrine/Doctrine/Data.php(222): Doctrine_Data_Import->doImport(false)
#5 /Users/argasek/Sites/test/library/doctrine/Doctrine/Core.php(1011): Doctrine_Data->importData('/Users/argasek/...', 'yml', Array, false)
#6 /Users/argasek/Sites/test/library/doctrine/Doctrine/Task/LoadData.php(43): Doctrine_Core::loadData('/Users/argasek/...', false)
#7 /Users/argasek/Sites/test/library/doctrine/Doctrine/Cli.php(516): Doctrine_Task_LoadData->execute()
#8 /Users/argasek/Sites/test/library/doctrine/Doctrine/Cli.php(498): Doctrine_Cli->executeTask(Object(Doctrine_Task_LoadData), Array)
#9 /Users/argasek/Sites/test/library/doctrine/Doctrine/Cli.php(452): Doctrine_Cli->_run(Array)
#10 /Users/argasek/Sites/test/scripts/doctrine-cli.php(29): Doctrine_Cli->run(Array)
#11

I have narrowed down the problem to the line 135 of Doctrine/Data/Import.php, ie.

if ($table->hasRelation($key) && is_array($value) && ! $table->hasTemplate('Doctrine_Template_I18n')) {

In case of GoogleI18n, $table->hasTemplate('Doctrine_Template_I18n') returns false.

I have no idea how to patch this in a sane way. Adding another condition (&& ! $table->hasTemplate('Doctrine_Template_GoogleI18n') serves well as a workaround, but such condition would be required for any class similar to Doctrine_Template_GoogleI18n. I guess the condition should check if it's a Doctrine_Template_I18n template or any template iherited from this class?...

Doctrine_Migration_Base::changeColumn doesn't change the DB column when using Postgres.

In Doctrine_Export_Pgsql::alterTableSql it checks for an index 'type' in the $field array, but the 'type' index is in $field['definition'], so we never enter there. Furthermore it then tries to get the type declaration with $this->conn->datatype->getTypeDeclaration($field['definition']) but there is no datatype property on the collection.
The attached patch should fix these problems.

I am not sure where to lay the blame for the following issue. I am using import->listTableColumns() to get the metadata of existing tables. I am then changing the name of the the columns in the tables retrieved using export->alterTable()... in general this seems to be working perfectly ok except for MYSQL LONGTEXT type fields. listTableColumns is returning the following schema:

'pn_value' =>
array
'name' => string 'pn_value' (length=8)
'type' => string 'string' (length=6)
'alltypes' =>
array
0 => string 'string' (length=6)
1 => string 'clob' (length=4)
'ntype' => string 'longtext' (length=8)
'length' => null
'fixed' => boolean false
'unsigned' => boolean false
'values' =>
array
empty
'primary' => boolean false
'default' => null
'notnull' => boolean false
'autoincrement' => boolean false

And when I send this to export->alterTable() it's generating the following SQL
ALTER TABLE z_module_vars CHANGE pn_value z_value VARCHAR(255)

So you can see it's truncating the field. The schema returned from the import of column definitions seems strange since there are two alltypes - and I wonder if that is why alterTables just assumes a string of 255 characters?

So I'm not sure which is to blame, if the import is returning invalid data, or that alterTableSql ultimately misinterprets it, but, the end result is an incorrect ALTER command.

As stated in DC-518 the getInstance method is added in table classes generated by Doctrine 1.2.2. The problem is, that the word order is wrong for the parameter keyword to support auto completion in IDEs. At least the NetBeans IDE is not able to use this information properly.

As it is common to expect phpDocumentor comment syntax, the first word after the @param keyword specifies the type, which is in the current version object. It would be really helpful if the current form could be changed from

* @return object %s

to

* @return %s

as it was propossed in the above mentioned issue.

After database is introspected, yaml file worked on for minor tweeks, and normal development cycle of drop database/rebuild database & sql, regular sql scrips and build in fuctions expecting the sequenced primary key columns to automatically create their own id from the sequence is broken. Found that in no case does this version of Doctrine put into the YML file

'nextval(sequenceName_seq'::regclass)

for the default value of the autoincrementing columns. Doing so should not affect any operation of the Doctrine library, as Doctrine gets the value independently by that exact call, and inserts that value into the column during inserts.

BUT, *NOT* having that as the default value BREAKS any SQL scripts or quick and dirty tasks via PGADMIN3 or any stored procedures expecting the column to assign itself the default value.

Summary, it won't hurt doctrine's operation
but it'll help non doctrine operations.

Seems like it should be done.

import/Oracle.php

foreach($result as $val)

'length' => $val['data_length'],
doesn't use the $decl = $this->conn->dataDict->getPortableDeclaration($val); witch make it Portable
use this instead
'length' => $decl['length'],

The import works only when i DISABLE the update relation. When i activate the update relation i get an sql error

SQLSTATE[23000]: Integrity constraint violation: 1452 Cannot add or update a child row: a foreign key constraint fails (`clubicious`.`location`, CONSTRAINT `location_updated_by_sf_guard_user_id` FOREIGN KEY (`updated_by`) REFERENCES `sf_guard_user` (`id`))

The relation is created correct i think the problem is in the importer???

Location:
actAs:
Timestampable: ~
Sortable: ~
Blameable:
columns:
created:
length: null
updated:
length: null
relations:
created:
disabled: false
class: sfGuardUser
updated:
disabled: false
class: sfGuardUser
columns:
name:

My fixtures:
sfGuardUser:
gfranke:
id: 1
first_name: Gordon
last_name: Franke
email_address: franke@clubicious.com
username: gfranke
password: startgf
Location:
location_atomic:
name: Atomic Cafe
CreatedBy: gfranke
UpdatedBy: gfranke

location_max:
name: Max & Moritz
CreatedBy: gfranke
UpdatedBy: gfranke

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;

I did change Doctrine/Export/Schema.php to pick up some options from model, then they get exported into YAML schema by current code.

Adding the patch. (sorry, can't run the tests, so I'm not sure whether it does break something, really shouldn't)

In my project it works just as expected (did need it for the way I do migrations).

TODO for Doctrine devs:

• run tests with my patch and let me know if there's a problem
• consider other option names, which are worth of export, so far I did need "charset" and "collate", and I added "queryParts" as well.

I hope my additions make sense and will help you to improve Doctrine project. (and that you will include it, so I don't have custom modified Doctrine )

The bugfix for DC-281 (r6802) contains an issue:

When between two tables in a MySQL database there are two relations, one on both sides (i.e. both tables have a FK field to each other), one of the two is overwritten with the second by the schema importer. That is, at one class, there seems to be only one relation instead of both.

The issue came in when the decision was made to store all class names in the definition array lower case, as one of the lookups in the array was not updated appropriately.

See Doctrine/Import.php (1.2.4) line 416 - 435. In line 427, you can clearly see the change made in 6802

Old:
$definitions[$relation['class']]['relations'][$alias] = array(
New:
$definitions[strtolower($relation['class'])]['relations'][$alias] = array(

Line 421 however should also have been updated:

if (in_array($relation['class'], $relClasses) || isset($definitions[$relation['class']]['relations'][$className])) {
Proposed fix:
if (in_array($relation['class'], $relClasses) || isset($definitions[strtolower($relation['class'])]['relations'][$className])) {

This error results in relations that already exist sometimes being overwritten.

line 121-128 of Doctrine_Export_Oracle appears to generate redundant code for creating a primary key constraint as primary keys (defined in schema.yml) are already generated during CREATE TABLE statements.

When attempting to reverse engineer databases using the generate-yaml-db task (via Symfony's doctrine:build-schema task), I've run into some issues due to table names not being compatible with PHP classnames. It creates the PHP classes in /tmp, setting the class name to the same as the table name, and then attempts to build the YAML files off of those.

I attempted to do this a few months ago and ran into issues because some of the table names began with numbers ("123MyTable" is not a valid PHP class name). My most recent attempt failed because of a table named "List", which is a reserved PHP keyword.

While I'm not sure if this is the ideal solution, I think allowing a way to pre-define a prefix for the generated PHP class names would be great.

Hi there,

When executing symfony doctrine:build --all --and-load on a machine using Mysql 5.0.44 I get the following error:

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 'dimension(id)' at line 1. Failing Query: "ALTER TABLE kpi_dimension ADD CONSTRAINT kpi_dimension_dimension_id_dimension_id FOREIGN KEY (dimension_id) REFERENCES dimension(id)".

The problem can be fixed by adding a space between the table name and the column name that is referenced. So instead of
REFERENCES dimension(id)
it should be
REFERENCES dimension (id)

Since it works fine on MySQL 5.1.37, I normally would file this under Mysql bug. But as the syntax for a foreign key constraint in MySQL mentions this space it should be ok to simply add the space to the script creating the sql for the foreign key. I have not tried any other DBMS though.

The patch for the file Export.php is attached.

Best regards

Claudia

I can't see the reason why Table classes are only generated if Base classes are... (the same occurs for Package classes, but regarding code comments a Package is required to extend a Base class... but a Table can't and won't...)

Here is some... patch? :s (it doesn't make unit tests to fail)

Best regards

Extending Doctrine_Template_I18n class make Doctrine_Import on YAML data with translation fails...

Why ? Just because of this line :

Doctrine_Import.php, line 135 :
if ($table->hasRelation($key) && is_array($value) && ! $table->hasTemplate('Doctrine_Template_I18n')) {

In fact, having a template named "Doctrine_Template_I18n" is not strong enough to be sure that the current object has an I18n behavior.

The bug is very simple to reproduce :

1. Get a classic I18n fixtures like :

Article:
Translation:
en:
title: Lorem Ipsum

2. Then make a simple extension of the I18n template (do not do anything else but extends the Doctrine_Template_I18n class) :

class My_Doctrine_Template_I18n extends Doctrine_Template_I18n {}

3. Load the extension, assign it to your model and try to import your fixtures again. It will not work anymore.

Thanks

Self assignments like:

$table = $table;

are unuseful and could be safely removed.