[DC-743] Incompatibilty between fixture import and accessors extends Created: 16/Jun/10  Updated: 22/Jul/11

Status: Open
Project: Doctrine 1
Component/s: Data Fixtures, Import/Export
Affects Version/s: 1.2.2
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Brice Favre Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 2
Labels: None
Environment:

Window, PHP5, Symfony



 Description   

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?



 Comments   
Comment by ryan [ 22/Jul/11 ]

this is the same issue as DC-735





[DC-735] Imported objects not converted to objects and parsed as string when a setter method exists Created: 14/Jun/10  Updated: 22/Jul/11

Status: Open
Project: Doctrine 1
Component/s: Import/Export
Affects Version/s: 1.2.2
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Kevin Dew Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 1
Labels: None
Environment:

Mac OS X 10.6



 Description   

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.



 Comments   
Comment by ryan [ 22/Jul/11 ]

added testcase here
https://github.com/rahx/doctrine1/commit/ba5628abaa5b3d60638d833d90b1cf439504d560





[DC-1045] data-load with invalid filename leads to purging of all the data in the database Created: 06/Dec/11  Updated: 06/Dec/11

Status: Open
Project: Doctrine 1
Component/s: Import/Export
Affects Version/s: 1.2.3
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Keszeg Alexandru Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

symfony 1.4


Attachments: Text File diff.patch    

 Description   

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.






[DC-1036] Doctrine_Export_Oracle::alterTable() not properly quoting column identifier for change Created: 07/Sep/11  Updated: 17/Apr/14

Status: Open
Project: Doctrine 1
Component/s: Import/Export
Affects Version/s: 1.2.2, 1.2.3
Fix Version/s: None

Type: Bug Priority: Major
Reporter: John Kary Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None


 Description   

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


 Comments   
Comment by John Kary [ 07/Sep/11 ]

Pull request opened with failing test case and bug fix:
https://github.com/doctrine/doctrine1/pull/40





[DC-1026] PgSQL driver does not create indexes on foreign key columns Created: 08/Aug/11  Updated: 17/Apr/14

Status: Open
Project: Doctrine 1
Component/s: Import/Export
Affects Version/s: 1.2.3
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Szurovecz János Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None


 Description   

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






[DC-1013] [PATCH] Doctrine ignores unique option for integers (PostgreSQL) Created: 29/Jun/11  Updated: 18/Aug/11

Status: Open
Project: Doctrine 1
Component/s: Import/Export
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Eugene Leonovich Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None

Attachments: Text File integer_unique.patch    

 Description   

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



 Comments   
Comment by MichalKJP [ 18/Aug/11 ]

Your patch fixed the problem for me. Thanks!





[DC-1004] ATTR_TBLNAME_FORMAT not used when creating models from database Created: 08/May/11  Updated: 17/Apr/14

Status: Open
Project: Doctrine 1
Component/s: Import/Export
Affects Version/s: 1.2.3
Fix Version/s: 1.2.3

Type: Bug Priority: Major
Reporter: Robin Parker Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None

Attachments: File doctrine_bug_diff.diff    

 Description   

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



 Comments   
Comment by Robin Parker [ 08/May/11 ]

The diff output as .diff





[DC-994] Doctrine_Data_Import creates unnecessary transactions, big slowdown Created: 05/Apr/11  Updated: 05/Apr/11

Status: Open
Project: Doctrine 1
Component/s: Import/Export
Affects Version/s: 1.2.3
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Krzysztof Bociurko / ChanibaL Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

MySQL, symfony doctrine:load-data


Attachments: Text File Doctrine_Data_Import-wrap-in-transaction.patch    

 Description   

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






[DC-955] Loading fixtures containing data for Versionable/Searchable Models fails due to Duplicate-Key errors Created: 14/Jan/11  Updated: 14/Jan/11

Status: Open
Project: Doctrine 1
Component/s: Behaviors, Data Fixtures, Import/Export, Searchable
Affects Version/s: 1.2.3
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Daniel Reiche Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 1
Labels: None
Environment:

PHP 5.3.3 / symfony 1.4.9-dev / MySQL 5.0



 Description   

Sample schema:

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

{ type: integer, primary: true, autoincrement: true }

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.






[DC-941] Spatial index type for mysql Created: 29/Nov/10  Updated: 29/Nov/10

Status: Open
Project: Doctrine 1
Component/s: Import/Export
Affects Version/s: 1.2.3
Fix Version/s: 1.2.3

Type: Improvement Priority: Major
Reporter: Mishal Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None

Attachments: Text File patch.patch    

 Description   

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






[DC-919] Import/Pgsql.php: listTableColumns - SQL failure with PostgreSQL Created: 07/Nov/10  Updated: 09/Apr/12

Status: Open
Project: Doctrine 1
Component/s: Import/Export
Affects Version/s: 1.2.3
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Christian Vogel Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 4
Labels: None
Environment:

Postgres Import Schema


Attachments: File trac_9152_patch_for_Pgsql.php.diff    

 Description   

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.

error
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"  


 Comments   
Comment by Nahuel Alejandro Ramos [ 09/Nov/10 ]

We apply the diff patch you submit and works perfect. We are using Doctrine 1.2.3 with PostgreSQL 8.4.
We could generates models from database with generateModelsFromDb() method.
Please add this patch to a new release.
Thank you very much.

Comment by Tim Hemming [ 23/Nov/10 ]

We have applied this patch directly to our server-wide Doctrine library and it works fine. We look forward to it becoming a part of the Doctrine distribution.

Comment by Christopher Hotchkiss [ 19/Dec/10 ]

I can confirm that this bug also affects symfony 1.4.8 and the attached fix works perfectly!

Comment by David Landgren [ 21/Feb/11 ]

Confirmed to fix crash with symfony 1.3.8

Comment by Cesar Miggiolaro [ 09/Apr/12 ]

I use the version 1.4.17 and also had the error with postgres 9.1. Applying the correction suggested in DIFF. The system worked.





[DC-892] Typo. in Import/Pgsql.php Created: 19/Oct/10  Updated: 31/Mar/11

Status: Open
Project: Doctrine 1
Component/s: Import/Export
Affects Version/s: 1.2.3
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Nicolas Ippolito Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 1
Labels: None
Environment:

Linux and symfony1.4.9



 Description   

Hi,

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

Thanks



 Comments   
Comment by Piotr Leszczyński [ 31/Mar/11 ]

Happens to me as well, on windows.





[DC-898] (PATCH) Migration fails when addColumn with type 'boolean' used with default value, resulting in incorrect 'ALTER TABLE' query in MySQL Created: 22/Oct/10  Updated: 17/Apr/14

Status: Open
Project: Doctrine 1
Component/s: Import/Export
Affects Version/s: 1.2.3
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Jakub Argasiński Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Mac OS X 10.6 Snow Leopard / Zend Server CE 5.0.3 (irrelevant)


Attachments: Text File fix_boolean_default_mysql_column_migration.patch    

 Description   

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

{main}

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.






[DC-871] When importing fixtures some times the fixtures will be loaded in the wrong order causing broken foreign key relations Created: 20/Sep/10  Updated: 20/Sep/10

Status: Open
Project: Doctrine 1
Component/s: Import/Export
Affects Version/s: 1.2.3
Fix Version/s: None

Type: Bug Priority: Major
Reporter: will ferrer Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

XP Xamp


Attachments: Text File DC_871_fix.patch    

 Description   

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



 Comments   
Comment by will ferrer [ 20/Sep/10 ]

Here is the patch





[DC-865] Models that extend a baseclass other than Doctrine_Record treat that baseclass as if it were a model Created: 11/Sep/10  Updated: 11/Sep/10

Status: Open
Project: Doctrine 1
Component/s: Cli, Import/Export
Affects Version/s: 1.2.3
Fix Version/s: None

Type: Bug Priority: Major
Reporter: will ferrer Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

XP Windows


Attachments: Text File DC_865_fix.patch    

 Description   

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



 Comments   
Comment by will ferrer [ 11/Sep/10 ]

Here is the patch





[DC-831] Importing fixtures fails when GoogleI18n used with "Couldn't create collection index. Record field 'lang' was null." Created: 17/Aug/10  Updated: 17/Apr/14

Status: Open
Project: Doctrine 1
Component/s: Data Fixtures, I18n, Import/Export
Affects Version/s: 1.2.2, 1.2.3
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Jakub Argasiński Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Mac OS X 10.6.4, Zend Server CE 5.0.2 (irrelevant, I guess)


Attachments: Text File fix_google18n_and_similiar_import_problem.patch    

 Description   

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

{main}

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



 Comments   
Comment by Jakub Argasiński [ 17/Aug/10 ]

I have provided a quick workaround patch for this problem, with an approach described in my report, ie. checking whether table has a template being an instance of or a child of Doctrine_Template_I18n.





[DC-798] Change column Postgres Created: 27/Jul/10  Updated: 19/Aug/10

Status: Open
Project: Doctrine 1
Component/s: Import/Export
Affects Version/s: 1.2.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Lea Haensenberger Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Mac OS X 10.6, doctrine 1.2, symfony 1.4, postgres 8.4


Attachments: Text File doctrine.patch    

 Description   

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.



 Comments   
Comment by Lukas Kahwe [ 27/Jul/10 ]

hmm .. seems like a refactoring issue with the old MDB2 code. same issue could be in other places too.

Comment by Lukas Kahwe [ 18/Aug/10 ]

may i commit the patch?

Comment by Jonathan H. Wage [ 18/Aug/10 ]

Do the other drivers reference the 'definition' too?

Comment by Jonathan H. Wage [ 18/Aug/10 ]

The other classes don't seem to reference the 'definition'. It looks like the information is right in the root of the array, why is it different in this case?

Comment by Lukas Kahwe [ 19/Aug/10 ]

ok the patch has been committed.

the others do also reference 'definition', its just that for mysql and sqlite the code is simpler because there you can just give a new definition, in postgresql you need to explicitly pass what you want to change and therefore the code needs to work differently.





[DC-793] import->listTableColumns / export->alterTableSql issues Created: 17/Jul/10  Updated: 17/Jul/10

Status: Open
Project: Doctrine 1
Component/s: Import/Export
Affects Version/s: 1.2.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Karma Dordrak (Drak) Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 1
Labels: None
Environment:

MySQL 5.1, PHP 5.3.1, Doctrine 1.2 branch latest.



 Description   

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.






[DC-789] Better documentation for the generated getInstance method in generated *Table.class.php files Created: 16/Jul/10  Updated: 16/Jul/10

Status: Open
Project: Doctrine 1
Component/s: Import/Export
Affects Version/s: 1.2.2
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Christoph Berg Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 2
Labels: None
Environment:

Symfony 1.4.6 with Doctrine 1.2.2 on Debian Linux 5.0



 Description   

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

Doctrine/Import/Builder.php:1077
* @return object %s

to

Doctrine/Import/Builder.php:1077
* @return %s

as it was propossed in the above mentioned issue.






[DC-783] Doing introspection of postgres datagbases with sequences for columns does not generate 'nextval(sequence_name)::regclass' for default value Created: 12/Jul/10  Updated: 12/Jul/10

Status: Open
Project: Doctrine 1
Component/s: Import/Export
Affects Version/s: 1.2.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Dennis Gearon Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

ubuntu/apache/postgres/php (LAP2/LAPP) Symfony 1.4.4 unmodified (orignal doctrine)



 Description   

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.



 Comments   
Comment by Dennis Gearon [ 12/Jul/10 ]

I tried manually adding the default value to the yml file and symfony/doctrine ignores it - it never gets set in the next newly created database. Hmmmmm.





[DC-733] Length validator fail because it was bad initialized Created: 14/Jun/10  Updated: 14/Jun/10

Status: Open
Project: Doctrine 1
Component/s: Import/Export
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Pierre Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Oracle



 Description   

import/Oracle.php

foreach($result as $val)

{ $val = array_change_key_case($val, CASE_LOWER); $decl = $this->conn->dataDict->getPortableDeclaration($val); $descr[$val['column_name']] = array( 'name' => $val['column_name'], 'notnull' => (bool) ($val['nullable'] === 'N'), 'ntype' => $val['data_type'], 'type' => $decl['type'][0], 'alltypes' => $decl['type'], 'fixed' => $decl['fixed'], 'unsigned' => $decl['unsigned'], 'default' => $val['data_default'], 'length' => $val['data_length'], 'primary' => $val['primary'] ? true:false, 'scale' => isset($val['scale']) ? $val['scale']:null, ); }

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






[DC-724] Blameable relations import problem Created: 09/Jun/10  Updated: 13/Jul/10

Status: Open
Project: Doctrine 1
Component/s: Extensions, Import/Export
Affects Version/s: 1.2.3
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Gordon Franke Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

symfony 1.4.5 with latest doctrine 1.2 branch with sfDoctrineGuardPlugin



 Description   

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:

{ type: string(255), notnull: true }

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



 Comments   
Comment by Tim Schofield [ 13/Jul/10 ]

Same Problem with Doctrine 1.2.2 and Zend Framework 1.10

Work around for me was to disable all Blameable relations in my schema.yml

Then run

./doctrine build-all-reload

So that fixtures can load

Then enable all Blameable relations in the schema.yml

and run

./doctrine generate-models-yaml

So models are generated with the correct relations

Regards

Tim





[DC-708] Wrong definition for MySQL string primary column Created: 28/May/10  Updated: 12/Jul/10

Status: Open
Project: Doctrine 1
Component/s: Import/Export
Affects Version/s: 1.2.2
Fix Version/s: 1.2.2

Type: Bug Priority: Major
Reporter: Claudio Nicora Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

PHP 5.3.1, WinXP-SP3, Doctrine 1.2.2, MySQL 5.1.41


Attachments: File export_mysql_patch.diff    

 Description   

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;


 Comments   
Comment by Claudio Nicora [ 28/May/10 ]

Attached a better patch where the notnull attribute is removed only if the primary column type is string

Comment by Claudio Nicora [ 28/May/10 ]

The same behaviour happens even for integer columns, so the notnull attribute should never be removed, not only for string columns. New patch attached, old one removed.

Comment by Jonathan H. Wage [ 08/Jun/10 ]

The patch I see currently just comments out the offending code. Is that intended? It cannot be committed if so

Comment by Claudio Nicora [ 08/Jun/10 ]

My patch only removed the effect, but it's not surely the best solution.

I've no sufficient knowledge on Doctrine to say that commenting out (or removing) that line will not affect other parts; that's why I only commented out the code instead of removing it (both on my side and on the attached patch).

If you think I'm not adding new bugs, I agree that removing the offending code is the cleanest way.

Comment by Jonathan H. Wage [ 08/Jun/10 ]

We can't just remove the code. It will change the behavior of the builder drastically which breaks backwards compatibility.

Comment by Claudio Nicora [ 08/Jun/10 ]

That's what I was afraid of.
Maybe you should change the code that generates the SQL for MySQL to make it include the "NOT NULL" clause to primary keys.

Comment by Jonathan H. Wage [ 08/Jun/10 ]

Hi, if you want to provide a patch that fixes your situation I can test it against our test suite and see if we can include it. You can also run your changes against the test suite to see if it causes any problems.

Comment by Claudio Nicora [ 13/Jun/10 ]

Hi, I attached a patch against Export/Mysql.php instead of the previous against Import/Builder.php.
It works on my side; can you please test it with your test suite?





[DC-689] Columns of type 'array' adds default clause to the create table statement which isn't supported by MySQL. Created: 18/May/10  Updated: 11/Jun/10

Status: Open
Project: Doctrine 1
Component/s: Import/Export
Affects Version/s: 1.2.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Daniel Holmstrom Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

MySQL version 5.0.83, Doctrine 1.2.2, Revision: 7490


Attachments: GZip Archive DC-689_example_patch.patch.gz    

 Description   

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.



 Comments   
Comment by Jonathan H. Wage [ 08/Jun/10 ]

Could you provide a test and patch?

Comment by Daniel Holmstrom [ 11/Jun/10 ]

(Un)fortunately I'll be computer-free for a month now, so I have no time to write test or do a proper patch. I'll attach the patch I use for reference.

Since the default clause depends on the native type which isn't known when the default clause is constructed (in getDefaultFieldDeclaration) I've simply added a check that sets the default clause to an empty string if the native type is one of those which isn't allowed to have a default value. I'm not sure, however, what the line in Doctrine/Export/Mysql.php::276:

{return $this->conn->dataDict->$method($name, $field);}

does and if that is affected by this also.

I guess you want the list of native types not allowed to have default values somewhere else, but I don't have the required knowledge about the internals of Doctrine to do this.

Comment by Daniel Holmstrom [ 11/Jun/10 ]

Attached patch giving example of how to fix DC-689.





[DC-655] When Export from Models to database is made some constraints may not be created Created: 29/Apr/10  Updated: 11/Jun/10

Status: Open
Project: Doctrine 1
Component/s: Import/Export
Affects Version/s: 1.2.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Oleg Stepura Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 2
Labels: None
Environment:

FreeBSD 6.1, Apache 2.2.4, PHP 5.3.2, MySQL 5.0.41



 Description   

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



 Comments   
Comment by Oleg Stepura [ 29/Apr/10 ]

Also what I noticed today is that this YAML schema:

Partner_Channel:
tableName: partner_channel
comment: List of channels.

Does not add comment to the MySQL table when trying to do this through the cli build-all-load command. Neither the generated Model nor the exported sql chema have this option ('comment').

maybe this should be a different bug report...

Comment by Guilliam X [ 11/Jun/10 ]

For your missing table comment, try nesting "comment" into "options", like this:

YAML
Partner_Channel:
  tableName: partner_channel
  options:
    comment: List of channels.

Now for the missing constraints issue, I confirm! See #DC-502

Comment by Oleg Stepura [ 11/Jun/10 ]

Hi! As for the comments - your decision seems like a workaround. Is it so or is it the way it should work? Do you know how this kind of stuff will work in 2.0 version?





[DC-615] New sequence generation for PostgreSQL SQL code results in errors Created: 02/Apr/10  Updated: 22/Jan/11

Status: Open
Project: Doctrine 1
Component/s: Import/Export
Affects Version/s: 1.2.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Maurice Makaay Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None

Attachments: File PostreSQL.createTableSql.sequence.fix.diff    

 Description   

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.



 Comments   
Comment by Maurice Makaay [ 03/Sep/10 ]

An additional issue for the PostgreSQL sequence handling: the Doctrine code does create a sequence field in the tables. However, the sequence system seems not to be in use at all for generating new id fields. As a result, the sequences remain at their initial value of 1.

We noticed this when we tried to manually insert a record in the database. Five records were already available. The manual INSERT failed, because of a duplicate index error on the id field. After a few attempts, it did work. That was because the PostgreSQL sequence had reached a value of 6, which was a non-existing id for the table at that point.

I think that a choice has to be made here: either use sequences or don't:

  • When id's are always generated without using the sequence features of PostgreSQL, then do not create the id fields as sequences, but make them standard primary key integer fields instead, so no unused sequence objects will be created in the database.
  • When id generation makes use of sequence features, then it's okay to use sequences for id fields. When doing this, loading a new dataset into the database might require some additional attention for the sequences. After import, the sequences should be updated to represent the first free id value for the table that it is providing id values for. When data import makes use of the sequences directly for generating id's, then this would not be necessary of course.

I hope this helps in improving Doctrine.

Comment by Maurice Makaay [ 22/Jan/11 ]

The issue with the duplicate id's is fixed on our system.

When defining "sequence: <something>" in a YAML file for a field, Doctrine will generate two sequences: one as specified in the YAML data and one as autogenerated by PostgreSQL. Doctrine inserts will use one, direct inserts via SQL will use the other. By specifying an field as primary and autoincrement, a correct and single sequence will be generated.

This work-around works for us. The Doctrine team will have to decide on what the expected behavior for "sequence" is. The current workings seem a bit off IMO.

I hope this helps. Thanks.





[DC-502] sometimes not all the constraints are created for a many to many relation Created: 15/Feb/10  Updated: 14/Jun/10

Status: Open
Project: Doctrine 1
Component/s: Import/Export, Relations
Affects Version/s: 1.2.0-ALPHA1, 1.2.0-ALPHA2, 1.2.0-ALPHA3, 1.2.0-BETA1, 1.2.0-BETA2, 1.2.0-BETA3, 1.2.0-RC1, 1.2.0, 1.2.1, 1.2.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Papp Richard Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 1
Labels: None
Environment:

i tried both under linux / win; with doctrine 1.1 / 1.2.1
tried with sandbox / direct creating "bootstrap" => same results...



 Description   

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:

schema.yml
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

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)



 Comments   
Comment by Piotr Karaś [ 20/Apr/10 ]

I seem to have a very similar issue. It is really annoying because no error feedback is given at any point...
In my case, one out of three many-to-many relations actually has its constraints created, the other two not.
However, if I take the file date/sql/schema.sql (I am working with Symfony 1.4.4) and run as an SQL query directly with my database, the constraints are created properly!

So, with symfony, if I go:
$ symfony14 doctrine:build-model
$ symfony14 doctrine:build-sql
$ symfony14 doctrine:insert-sql
The model gets generated, the database gets generated, but several many-to-many constrains are missing.

Then if I go:
$ symfony14 doctrine:build-model
$ symfony14 doctrine:build-sql
$ mysql -u user -p database < date/sql/schema.sql
The model gets generated, the database gets generated, and the constraints are in place.

Hope this helps to have the problem fixed.

Cheers,
Piotrek

Comment by Guilliam X [ 11/Jun/10 ]

I do confirm this "alphabetical-order exporting" problem! (in 1.2 svn revision 7676)
(see also #DC-655)

*Edit:* I have gone closer through the functions calls and used a debugger, and the problem is actually logical;
it happens whenever a refClass of a many-to-many relation is parsed (and exported) before one or both of the linked classes.

Let's take this schema (YAML is shorter, anyways the generated PHP models are not bugged):

schema.yml
---
LinkTable:
  columns:
    table1_id:
      primary: true
      type:    integer
    table2_id:
      primary: true
      type:    integer
Table1:
  relations:
    Table2:
      refClass: LinkTable
      local:    table1_id
      foreign:  table2_id
Table2:
  relations:
    Table1:
      refClass: LinkTable
      local:    table2_id
      foreign:  table1_id

Now if you call Doctrine_Core::createTablesFromModels() or Doctrine_Core::generateSqlFromModels(), consequent call to Doctrine_Export::exportSortedClassesSql() does a loop and calls exportClassesSql() for each model in alphabetical order; once a table has been exported, subsequent bindings of pending relations won't be "retro-parsed" for the export.

I tried to compact the calls chain:

php
/* IN CLASS Doctrine_Export (or child (connection export)) */

$this->exportSortedClassesSql($classes)
{
    FOREACH ($classes as $class) {
        $connection = Doctrine_Manager::getInstance()->getConnectionForComponent($class);
        //...
        $sql =
        $connection->export->exportClassesSql($models = array($class))
        {
            FOREACH ($models as $name) {
                $record = new $name();
                $table = $record->getTable();
                //...
                $data = $table->getExportableFormat()
                {
                    /* IN CLASS Doctrine_Table (or child) */
                    
                    //...
                    $this->_parser->getRelations()
                    {
                        /* IN CLASS Doctrine_Relation_Parser (or child) */
                        
                        FOREACH ($this->_pending as $alias => $v) {
                            $this->getRelation($alias)
                            {
                                //...
                                /*
                                 * In the case of an "association relation" through a refTable:
                                 *   binds a *pending* (simple foreign key) relation to the refTable parser,
                                 *   binds a *pending* (simple foreign key) relation to itself,
                                 *   and "finalizes" (adds to $this->_relations) its association relation
                                 */
                            }
                        }
                    }
                    //...
                }
            }
        }
    }
}

So, with our example schema,

  1. LinkTable is exported with no constraints (because has no relations at this time);
  2. Table1 gets parsed, which finalizes the pending relation with Table2 (binded when loaded), binds to itself a pending relation with LinkTable, and binds to LinkTable parser the first pending relation (with Table1); Table1 is then exported whilst it still has a pending relation;
  3. Table2 gets parsed and exported the same way.

So now we have 2 problems:

  • each table has been exported immediately after its parsing, i.e. in an incomplete state (this is the present issue)
  • even after the whole relations parsing loop, LinkTable has still 2 pending relations, and each of both other tables has one "final" and one pending (but maybe it is supposed to be so...)

Note that a second call to Doctrine_Core::generateSqlFromModels() just after the first one, will parse all models one more time and thus finalize those pending relations, generating all constraints (also will subsequent calls).

For now I don't have a fix but I think we could consider:

  • loop twice in Doctrine_Export::exportSortedClassesSql() and exportClassesSql(), and construct SQL queries only the 2nd time (but... hum...)
  • improve Doctrine_Relation_Parser? maybe explicitly call getRelations() after each bind() (in the getRelation() function)...

Anyway it seems clear that export shouldn't be done before all tables have been parsed.

G.X

Comment by Guilliam X [ 12/Jun/10 ]

I still have no fix but in the waiting we can still discuss some "user-side" work-arounds (that don't need modifying Doctrine source code)...
Here is what crosses my mind first:

  • (in the PHP working code) do a first "dummy" call to
    $conn->export->exportClassesSql(Doctrine_Core::loadModels('models'))

    just to ensure all relations are bound, then a "real" call to Doctrine_Core::createTablesFromModels('models') which will export all constraints well

  • (in the schema) rename LinkTable to something like ZzLinkTable so that it is exported last
  • "explicitize" the two (one-to-many) foreign key relations in LinkTable by completing the schema as follows:
    schema.yml
    ---
    LinkTable:
      columns:
        table1_id:
          primary: true
          type:    integer
        table2_id:
          primary: true
          type:    integer
    #(added)
      relations:
        Table1:
          local:   table1_id
          foreign: id
        Table2:
          local:   table2_id
          foreign: id
    #(/added)
    Table1:
      relations:
        Table2:
          refClass: LinkTable
          local:    table1_id
          foreign:  table2_id
    Table2:
      relations:
        Table1:
          refClass: LinkTable
          local:    table2_id
          foreign:  table1_id
    

    (I think this one would also "solve" the behavior problem of Papp Richard)

But I'm not that happy with the idea of choosing one of these "hacks" if I had to, I would use this last one but (unless you use some "onDelete: CASCADE" or so) it looks like unnecessary duplication...
Someone, any other idea? ^^

G.X

(edit: typo fix)

Comment by Guilliam X [ 13/Jun/10 ]

We can try another approach too: let's say that our generated PHP models classes are incomplete.

Indeed, for a simple foreign key relation (i.e. o2o and o2m / m2o), we can define it only once on the owning side in the YAML file, and the schema importer will generate complete PHP classes, with the "hasOne" on the owning side and the auto-completed "hasMany" on the opposite side. E.g:

YAML schema
Phonenumber:
  columns:
    user_id: integer
  relations:
    User: {local: user_id, foreign: id}
User:
# we don't precise the opposite relation here

will generate the following classes (simplified a bit):

PHP models (1)
// models/Phonenumber.php
class Phonenumber extends Doctrine_Record
{
    public function setTableDefinition() {
        $this->hasColumn('user_id', 'integer');
    }

    public function setUp() {
        $this->hasOne('User', array('local'   => 'user_id',
                                    'foreign' => 'id'));
    }
}

// models/User.php
class User extends Doctrine_Record
{
    public function setTableDefinition() {
    }

    public function setUp() {
        // this was auto-added during the schema import:
        $this->hasMany('Phonenumber', array('local'   => 'id',
                                            'foreign' => 'user_id'));
    }
}

and this will work well.
BUT, now if we remove the auto-added hasMany() in User.php, then run the following (which worked well before our manual modification):

test.php
require_once 'bootstrap.php';

$user = new User();
Doctrine_Core::dump($user->Phonenumber);

we get some Fatal error: Uncaught exception 'Doctrine_Record_UnknownPropertyException' with message 'Unknown record property / related component "Phonenumber" on "User"', which is supposed to occur. Indeed, how could Doctrine know that a User has a "link" with Phonenumber? It would be only possible by parsing the relations of all the (loaded) models first...

So we can say that YAML schema files can be incomplete whereas PHP models classes MUST be COMPLETE.

Now, considering it is not to change, why not apply this "principle" to (m2m) association relations?
i.e., Doctrine documentation could warn that, if you want to have all constraints properly exported (like in the present issue) and/or use relations from an association class (having $link instance of LinkTable, you want to use $link->Table1, not just $link->table1_id), then you MUST complete your PHP models with the FK relations, like this:

PHP models (2)
// models/LinkTable.php
class LinkTable extends Doctrine_Record
{
    public function setTableDefinition() {
        $this->hasColumn('table1_id', 'integer', null, array(
                'primary' => true));
        $this->hasColumn('table2_id', 'integer', null, array(
                'primary' => true));
    }

    public function setUp() {
        // ADD:
        $this->hasOne('Table1', array('local'   => 'table1_id',
                                      'foreign' => 'id'));
        $this->hasOne('Table2', array('local'   => 'table2_id',
                                      'foreign' => 'id'));
    }
}

// models/Table1.php
class Table1 extends Doctrine_Record
{
    public function setTableDefinition() {
    }

    public function setUp() {
        $this->hasMany('Table2', array('refClass' => 'LinkTable',
                                       'local'    => 'table1_id',
                                       'foreign'  => 'table2_id'));
        // add too?:
        $this->hasMany('LinkTable', array('local'    => 'id',
                                          'foreign'  => 'table1_id'));
    }
}

// models/Table2.php
class Table2 extends Doctrine_Record
{
    public function setTableDefinition() {
    }

    public function setUp() {
        $this->hasMany('Table1', array('refClass' => 'LinkTable',
                                       'local'    => 'table2_id',
                                       'foreign'  => 'table1_id'));
        // add too?:
        $this->hasMany('LinkTable', array('local'    => 'id',
                                          'foreign'  => 'table2_id'));
    }
}

After all, these additional relations are bound internally (if not already defined) when exporting tables to DB...

We also said that the YAML can be incomplete, but for now the short schema.yml I took as an example in my first comment results in PHP classes without those (2+1+1) adds.

So to allow YAML to be incomplete even for m2m relations, Doctrine_Import_Schema#_buildRelationships() would need some "improvement" so that it creates the many-to-one relation for each many-to-many relation (and the opposite one-to-many relation, on the association class side i.e. the owning side, would be auto-completed afterwards). However, a m2m relation is allowed to be defined on one single end, thus may be created one the other end only when _autoCompleteOppositeRelations() is called, i.e. after _buildRelationships() has looped over all the existing relations. So Doctrine_Import_Schema#_autoCompleteOppositeRelations() would need the same kind of improvement...

In fact I'm not sure of what is a "well defined" model as soon as it uses refClass, the documentation sometimes uses contradictory examples...

Sorry I was so verbose!
Thank you for developing Doctrine





[DC-473] createIndexSql() and dropIndexSql() use different index names (formatter) on MySQL and Postgres Created: 02/Feb/10  Updated: 08/Jun/10

Status: Open
Project: Doctrine 1
Component/s: Import/Export
Affects Version/s: 1.2.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Michael Piecko Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Postgres 8.3, MySQL 5.0



 Description   

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



 Comments   
Comment by Jonathan H. Wage [ 15/Mar/10 ]

Hi, can you provide either a patch or failing test case that shows the issue so that I can write a patch for it? Thanks, Jon

Comment by Michael Piecko [ 18/Mar/10 ]

I must admit that i never did that (patch). And i know i should. I'll work on that over the weekend.

Michael

Comment by Jonathan H. Wage [ 08/Jun/10 ]

You can just make your changes and then run svn diff in the Doctrine directory and it will produce a patch/diff which you can attach here.





[DC-368] createTablesFromModels() wants to create already existing FOREIGN KEY constraints Created: 18/Dec/09  Updated: 24/Aug/10

Status: Open
Project: Doctrine 1
Component/s: Import/Export
Affects Version/s: 1.2.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Mike Reiche Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 1
Labels: None
Environment:

mysql Ver 14.12 Distrib 5.0.75, for debian-linux-gnu (i486) using readline 5.2
PHP 5.2.11-0.dotdeb.1 with Suhosin-Patch 0.9.7 (cli) (built: Sep 20 2009 09:41:43)
Ubuntu 9.04


Attachments: Text File schema.txt     Zip Archive testcase.zip    

 Description   

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)



 Comments   
Comment by Mike Reiche [ 18/Dec/09 ]

Moved model and setup code from description to attachment.

Comment by Michal Olszewski [ 09/Feb/10 ]

Hi,

Just a quick comment - the test case you've provided works fine for me using 1.2.1 and also latest code from 1.2 branch... you might try that.

The error above (1005) is caused by mismatch between local and foreign key definitions. So it seems somewhere along the lines you/Doctrine messed up field definitions (although I can't see it provided test case). Try using integer without length definition in YAML, like:

id:
type: integer
autoincrement: true
primary: true

and check if this is working.

Comment by PpW8bNH3jy2A [ 01/Mar/10 ]

I'm having the same issue. However, I've tried the test case using a sqlite memory only database and i can't trigger the problem.

Here's my mysql schema, for your review - which does trigger the issue using 1.2.1.

Comment by PpW8bNH3jy2A [ 01/Mar/10 ]

I put some debugging statements in Doctrine/Export.php around line 1216:
------------
$connection->exec($query);
} catch (Doctrine_Connection_Exception $e) {
// we only want to silence table already exists errors
+ print_r($e->getPortableCode());
+ print_r(Doctrine_Core::ERR_ALREADY_EXISTS);
+ print_r($e->getMessage());
+ echo "<br><br>";
+// exit;
+
+
if ($e->getPortableCode() !== Doctrine_Core::ERR_ALREADY_EXISTS) {
$connection->rollback();

----------------------

Here's the output I get:

-5-5SQLSTATE[42S01]: Base table or view already exists: 1050 Table 'category' already exists. Failing Query: "CREATE TABLE category (id BIGINT AUTO_INCREMENT, name VARCHAR(80), company_id BIGINT, INDEX company_id_idx (company_id), PRIMARY KEY(id)) ENGINE = INNODB"

-5-5SQLSTATE[42S01]: Base table or view already exists: 1050 Table 'company' already exists. Failing Query: "CREATE TABLE company (id BIGINT AUTO_INCREMENT, name VARCHAR(80) UNIQUE, address1 VARCHAR(80), address2 VARCHAR(80), city VARCHAR(80), state VARCHAR(10), zipcode VARCHAR(20), phone VARCHAR(20), fax VARCHAR(20), url VARCHAR(255), logo VARCHAR(255), perferedcolumn BIGINT, randomsort BIGINT, comment LONGTEXT, PRIMARY KEY(id)) ENGINE = INNODB"

-5-5SQLSTATE[42S01]: Base table or view already exists: 1050 Table 'user' already exists. Failing Query: "CREATE TABLE user (email VARCHAR(255), password VARCHAR(80), fullname VARCHAR(80), company_id BIGINT, cellphone VARCHAR(20), voice VARCHAR(20), voiceext VARCHAR(20), fax VARCHAR(20), comment LONGTEXT, status TINYINT(1), admin TINYINT(1), timeadded DATETIME, timechagned DATETIME, INDEX company_id_idx (company_id), PRIMARY KEY(email)) ENGINE = INNODB"

-15-5SQLSTATE[HY000]: General error: 1005 Can't create table './iprfpartners/#sql-7eeb_2d8.frm' (errno: 121). Failing Query: "ALTER TABLE category ADD CONSTRAINT category_company_id_company_id FOREIGN KEY (company_id) REFERENCES company(id)"

Comment by B. Ariston Darmayuda [ 23/Aug/10 ]

I have same problem, but this problem is face on db engine side. When we look at the last query sql like:

ALTER TABLE category ADD CONSTRAINT category_company_id_company_id FOREIGN KEY (company_id) REFERENCES company(id)

The first call of createTablesFromModels will create the table and add contraint which run fine because table and constraint not exist yet. Then when we execute createTablesFromModels again it will fail because it still try to create constraint which already exist on table. I'm still looking on MySql section how to check the constrain if it exist or not. If the constraint not exist then we can execute the sql above, if not we need to avoid execution for sql above, this mean we cannot MODIFY the constrain (like ON UPDATE and ON DELETE mode).

Comment by B. Ariston Darmayuda [ 24/Aug/10 ]

I've figure out the errorno: 121 which I thinking is that the process try re-adding existing CONSTRAINT name. The resolve that I've found is for MySQL engine and modify some Doctrine libraries.

1. I've modify Doctrine_Export_Mysql by adding override function of:

public function createForeignKeySql($table, array $definition)
{
    $tableInfo = $this->conn->execute('SHOW CREATE TABLE '.$this->conn->quoteIdentifier($table));
    if ($tableInfo && ($row = $tableInfo->fetch()))
      if ($row['Create Table'] && preg_match('/CONSTRAINT `'.$definition['name'].'`.+/i', $row['Create Table'])) return '';
    return parent::createForeignKeySql($table, $definition);
}

2. Since if CONSTRAINT already exist the createForeignKeySql return empty string, we need modify function on Doctrine_Export with:

public function createForeignKey($table, array $definition)
{
    $sql = $this->createForeignKeySql($table, $definition);
    if ($sql != '')
      return $this->conn->execute($sql);
    else
      return -1;
}

Now by add/modify function above I can savely run createTablesFromModels because if CONSTRAINT of a table exist on database the ALTER TABLE ... ADD CONSTRAINT will not generated. Hope this can help some of you guys.





[DC-321] Doctrine/Import/Mssql.php does not handle default values Created: 03/Dec/09  Updated: 03/Dec/09

Status: Open
Project: Doctrine 1
Component/s: Import/Export
Affects Version/s: 1.2.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: aiso haikens Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

using odbc connection to sql server. (SQL Native Client)



 Description   

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.






[DC-1065] http://www.doctrine-project.org/jira/browse/DC-98 Created: 17/Jul/14  Updated: 17/Jul/14

Status: Open
Project: Doctrine 1
Component/s: Import/Export
Affects Version/s: 1.2.3
Fix Version/s: None

Type: Bug Priority: Major
Reporter: BizLogic Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: bug, generation, model, patch
Environment:

Linux, PHP


Attachments: File Builder.php    
Issue Links:
Duplicate
duplicates DC-98 Generated base class file names get e... Resolved

 Description   

Doctrine 1.2.4 does not respect the variable baseClassPrefixFiles when generating models.
Generated base files will always have the prefix specified in the baseClassPrefix variable.

Example PHP Code:
		Doctrine_Core::generateModelsFromDb(
			BASEDIR.'/application/models',
			array('doctrine'),
			array(	
				'generateTableClasses'	=> true, 
				'baseClassPrefix'		=> 'Generated_',
				'baseClassesDirectory'	=> 'Generated',
				'baseClassPrefixFiles'	=> false,
				'classPrefixFiles'		=> false
			)
		);

A patched version of ./Doctrine/Import/Builder.php is attached



 Comments   
Comment by BizLogic [ 17/Jul/14 ]

http://www.doctrine-project.org/jira/browse/DC-98?focusedCommentId=23753&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-23753





[DC-1005] Schema importer sometimes overwrites relations (instead of adding them) due to issue with bugfix DC-281 Created: 17/May/11  Updated: 17/May/11

Status: Open
Project: Doctrine 1
Component/s: Import/Export
Affects Version/s: 1.2.0, 1.2.1, 1.2.2, 1.2.3
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Pelle ten Cate Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None


 Description   

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.






[DC-987] redundant sql statement in Doctrine_Export_Oracle::_makeAutoincrement() Created: 21/Mar/11  Updated: 21/Mar/11

Status: Open
Project: Doctrine 1
Component/s: Import/Export
Affects Version/s: 1.2.3
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: David Dixon Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

linux, oracle



 Description   

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.






[DC-864] Generating YAML schema from model should pick up also charset, collate and other options Created: 10/Sep/10  Updated: 10/Jan/11

Status: Open
Project: Doctrine 1
Component/s: Import/Export, Schema Files
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: Peter Helcmanovsky Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None

Attachments: Text File Export_Schema.patch    

 Description   

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 )



 Comments   
Comment by Peter Helcmanovsky [ 10/Jan/11 ]

By hunting down an eluding bug I figured out (i.e. by hard way) that the indexes are dropped as well during YAML generation.

I will do another pull request on github including another 3 lines to fix that...

I see this issue is ignored anyway by core devs.





[DC-780] Foreign key creation fails with MySQL 5.0.44 Created: 09/Jul/10  Updated: 09/Jul/10

Status: Open
Project: Doctrine 1
Component/s: Import/Export
Affects Version/s: 1.2.0
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Claudia Kosny Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

gentoo, MySQL 5.0.44-log, Doctrine 1.2, symfony 1.4.4


Attachments: Text File Doctrine-Export.patch    

 Description   

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






[DC-737] generateModelsFromYaml with (generateTableClasses = true) doesn't generate tables classes if (generateBaseClasses = false) Created: 15/Jun/10  Updated: 15/Jun/10

Status: Open
Project: Doctrine 1
Component/s: Import/Export
Affects Version/s: 1.2.2
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Guilliam X Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Doctrine SVN 1.2 r.7676


Attachments: Text File DC-737.patch    

 Description   

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






[DC-457] Generating YAML schema from DB breaks on certain table names Created: 26/Jan/10  Updated: 17/Mar/10

Status: Reopened
Project: Doctrine 1
Component/s: Import/Export
Affects Version/s: 1.2.1
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: Ari Pringle Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Linux, Symfony 1.4.1, Doctrine 1.2.1



 Description   

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.



 Comments   
Comment by Stefan [ 22/Feb/10 ]

I think there seems to be a general problem in usage of table names, when using the generating from database to yml.

I think there something changed with the naming stragegies in the last versions (I do not know in wich one), but it works with doctrine 1.0.10 (used in symfony 1.2.8).

theoretical stragegies:
1. Only the first letter is a capital (e.g. ProjectCategory --> Projectcategory)
2. When a _ is inside the name, the _ is removed an a capital will used (e.g. Project_Values --> ProjectValues)

But doctrine does not make use of this anymore. When I generate with doctrine 1.2.1 (used in symfony 1.3.2) my table ProjectCategory will be named as ProjectCategory in schema. And when the schema is wrong, all generated models are incompatible to older versions.

Comment by Jonathan H. Wage [ 01/Mar/10 ]

Hmm. I don't quite understand. I tested the things you described and it all works as I expected it to. You'll have to provide some more information.

Comment by Ari Pringle [ 17/Mar/10 ]

Sorry for the delay in response.

Here's how to reproduce my original issue (I should also mention that I'm running PHP 5.2.4):

mysql> create table List (id int not null auto_increment,primary key(id));
bash$ ./symfony doctrine:build-schema
>> doctrine  generating yaml schema from database

Parse error: syntax error, unexpected T_LIST, expecting T_STRING in /tmp/tmp_doctrine_models/List.php on line 17

bash$ sed -n '17p' /tmp/tmp_doctrine_models/List.php 
class List extends Doctrine_Record

The same thing happens if the table name begins with a number (ie 123MyTable).

Again, I'm not sure if this is the ideal solution, but being able to define a prefix to the generated class names would take care of this issue (so the generated class name above could be MyPrefix_List instead of List)





[DC-1029] Extensions of Doctrine_Template_I18n incompatible with Doctrine_Import Created: 18/Aug/11  Updated: 17/Apr/14

Status: Open
Project: Doctrine 1
Component/s: Data Fixtures, I18n, Import/Export
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Trivial
Reporter: Pierrot Evrard Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Windows 7, XAMPP 1.7.4 with APC and Curl, symfony 1.4.8


Attachments: Text File DC-1029.patch    

 Description   

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



 Comments   
Comment by Pierrot Evrard [ 18/Aug/11 ]

See this patch where to check if the table has the I18n plugin, I check if one of the templates has a getI18n() method.

This is probably not strong enough but it can do the job until you find a better solution.

Thanks

Comment by Pierrot Evrard [ 18/Aug/11 ]

Another possibility to check that templates are I18n template, will be to create an Doctrine_I18n_Interface. Also, every template that include this interface can be considered as I18n templates.

What do you think about that ?

NB: May the interface can define the method getI18n() to be declared...





[DC-784] Removed unuseful code Created: 13/Jul/10  Updated: 13/Jul/10

Status: Open
Project: Doctrine 1
Component/s: Import/Export
Affects Version/s: 1.2.2
Fix Version/s: None

Type: Improvement Priority: Trivial
Reporter: Claudio Nicora Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None

Attachments: File patch.diff    

 Description   

Self assignments like:

$table = $table;

are unuseful and could be safely removed.






Generated at Sun Dec 21 23:22:27 UTC 2014 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.