[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-983] Fixtures loading is repeated for each database connections Created: 08/Mar/11  Updated: 08/Mar/11

Status: Open
Project: Doctrine 1
Component/s: Data Fixtures
Affects Version/s: None
Fix Version/s: None

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


 Description   

Bug found when working on project ma-residence.fr. Data loading was repeated twice, and in the second run, empty rows were inserted in database, resulting in major headache in development team.

A same flush tree is built for each connections. It results in multiple loops of data load when there is more than one connection.



 Comments   
Comment by Ludovic Vigouroux [ 08/Mar/11 ]

A proposition to fix it is on github https://github.com/ludovig/doctrine1





[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-940] Doctrine - loading a YAML fixture with French characters, replaces the accents with junk Created: 26/Nov/10  Updated: 26/Nov/10

Status: Open
Project: Doctrine 1
Component/s: Data Fixtures
Affects Version/s: 1.2.3
Fix Version/s: None

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

MAC OS X (10.6.5)
MAMP 1.9.4
PHP 5.3.2



 Description   

Hi,

My Doctrine 1.2 is integrated inside CodeIgniter as a hook and I know that my char-set is utf8 with collation utf8_unicode_ci.

I have two YAML files, one for creating the DB and its tables and one to load some test data. My data can contain French accents (çéïë...). In my schama.yml I have correctly specified the collation and char-set:

options:
type: INNODB
charset: utf8
collate: utf8_unicode_ci

I double checked the settings in phpMyAdmin, everything is correct.

When I run my doctrine script from commandline to load my fixture to populate one of tables, all the French accents are replaced by junk!

Am I missing a setting or configuration or is there a bug in Doctrine?

I appreciate any help. Cheers.

P.S. Everything else works like a charm






[DC-938] Impossible to use other formats than YAML in data import Created: 25/Nov/10  Updated: 25/Nov/10

Status: Open
Project: Doctrine 1
Component/s: Data Fixtures
Affects Version/s: 1.2.3
Fix Version/s: None

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


 Description   

File Doctrine/Data/Import.php, line #80
if (end($e) == 'yml')

So, if the file is a .json (for exemple), it will be impossible to load it, even if we have specified "json" as format parameter.
And it sucks.

The fix would just be to change the line to :
if (end($e) == $this->getFormat())






[DC-863] Connection.UnitOfWork::buildFlushTree when loading data from yml file, Incorrect ordering of tables by their relations Created: 10/Sep/10  Updated: 17/Apr/14

Status: Open
Project: Doctrine 1
Component/s: Connection, Data Fixtures
Affects Version/s: 1.2.0, 1.2.1, 1.2.2, 1.2.3
Fix Version/s: None

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

symfony 1.4.6, windows 7, apache2.2, php5.3.3, mySQL 5.1.49-community


Attachments: File schema.yml     File test.yml    

 Description   

I don't know where exactly to start, I'm new here, and i'm not even sure this is a bug. BUT

We have a database structure with most important tables' PK's as string fields, which function as FK on other tables the basic structure is:

Artist
-Album
-Song
-Comments

each artist has multiple songs
each artist has multiple albums
each album has multiple songs that belong to the same artist as the album belongs to
each song has multiple comments

thus, the UnitOfWork - builtFlushTree should generate

[0]=>Artist
[1]=>Album
[2]=>Song
[3]=>Comments

but instead i get:
[0] => Album
[1] => Artist
[2] => Song
[3] => Lyrics

which in turn generates:

QLSTATE[23000]: Integrity constraint violation: 1452 Cannot add or update a child row: a foreign key constraint fails (`lyrics`.`album`, CONSTRAINT `album_artist_fk_stripped_name_artist_stripped_name` FOREIGN KEY (`artist_fk_stripped_name`) REFERENCES `artist` (`stripped_name`) ON DELETE CASCADE ON UPDATE CASC)
obviously.

I've been going through symfony/doctrine code for a whole day trying to figure out why I can't load-data. in the end i get to this buildFlushTree function.
probably have to go deeper. but so far this is it

PS. It's my decision to use string fields as PK's and FK even though it's a bad practice, but just because it is a bad practice I shouldn't be unable to work with it.



 Comments   
Comment by Ochoo [ 10/Sep/10 ]

found a tiny BUG, submitting the fix.

EDIT: scratch the rest from here.

<!-----------
still, fixing the bug does not resolve the issue
BECAUSE:
the whole logic of ordering the tables is flawed! it can be proved, don't have time to do so. but trying to come up with a fix myself

instead of looping through the tables and then through each tables' related tables, either have a recursive function OR implement user defined array sort function, latter of which seems like the proper and correct way to go
-->

Comment by Ochoo [ 10/Sep/10 ]

unfortunately i'm unable to commit any changes i have made. just me being a newbie, any help is appreciated

Comment by Ochoo [ 10/Sep/10 ]

on UnitOfWork.php of Doctrine ORM 1.2.3
Revision 7684
right after the line 752:
array_splice($flushList, $index, 0, $relatedClassName);
there should be:
$index++;

Comment by atali daoud [ 29/Nov/10 ]

@Ochoo: Even with your bugfix, it doesn't seem to work.

Comment by Ochoo [ 01/Dec/10 ]

thanks atali, i haven't checked it on 1.2.3, just did and you're right. the "bug fix" worked on 1.2.0 but not on 1.2.3. I'm gonna look into it, at least i'll try. but this is a bug right?





[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-322] Data dump fails on tables with quoted identifiers Created: 03/Dec/09  Updated: 04/Dec/09

Status: Open
Project: Doctrine 1
Component/s: Data Fixtures
Affects Version/s: 1.2.0
Fix Version/s: None

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

linux, apache 2, mysql 5.1, php 5.2



 Description   

While dumping a table with a quoted identifier `numeric`, doctrine failed because the constructed query had an invalid alias the field: c__`numeric`.

Output:
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 '`numeric`, c.alpha3 AS c_alpha3, c.alpha2 AS calpha2 FROM country_codes c' at line 1. Failing Query: "SELECT c.country AS ccountry, c.`numeric` AS c`numeric`, c.alpha3 AS calpha3, c.alpha2 AS c_alpha2 FROM country_codes c"

I know that using quoted identifiers is discouraged but I think this could be easily solvable.

Thanks.



 Comments   
Comment by Juozas Kaziukenas [ 03/Dec/09 ]

In which code part are you quoting that column? Because just enabling identifiers quoting would result in completely different results (at least there will be all columns quotes or none).

Comment by Massimiliano Torromeo [ 04/Dec/09 ]

I'm not using Doctrine::ATTR_QUOTE_IDENTIFIER, I generated a yaml from a preexisting db and then adapted it.

It generated the following definition:
CountryCodes:
columns:
country:
type: string(32)
notnull: true
`numeric`:
type: integer(2)
unsigned: 1
primary: true
alpha3:
type: string(3)
fixed: true
notnull: true
alpha2:
type: string(2)
fixed: true
notnull: true

but it was with an old version of Doctrine and this is not the case anymore (I tried regenerating it). I assumed it was correct to quote one single identifier, but I now guess it wasn't.

I think this can be closed as NotBug.

Sorry for the trouble.
Regards.

Comment by Juozas Kaziukenas [ 04/Dec/09 ]

However, variables cannot be quoted like that - quoting happens after actual columns are constructed, so now Doctrine needs to unquote it and do it's stuff. If you want quoting - enable that option and it will do it for you, or the best - don't use reserved words in your schema

This issue can be closed as Invalid.





[DC-852] CLONE -Fix returned type value : SQL integers to PHP integers when getting a value from the database. Created: 01/Sep/10  Updated: 17/Apr/14

Status: Open
Project: Doctrine 1
Component/s: Attributes, Data Fixtures, Native SQL, Query, Record
Affects Version/s: 1.2.3
Fix Version/s: None

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


 Description   

Hi Jon,

I have a request for you to improve Doctrine. When declaring a column as an integer, it seems that Doctrine returns a string when getting the value of that column. For example, if I have a "status" column, which can take 0, 1 or 2 as its value, Doctrine will return these values as string, which is not really logical and returning the good PHP type is the goal of an ORM. I'm fond of the triple equal symbol to test a value and I did not understand why this did not work at start :

// in my myModel class
class myModel extends Doctrine_Record
{
const STATUS_VALIDATED = 1;

public function isValidated()

{ return self::STATUS_VALIDATED === $this->getStatus(); }

}

That's why getStatus() gives me a string instead of an integer, whereas the column is declared as an integer in my schema. I'm forced to cast myself the returned value of getStatus() in my model.



 Comments   
Comment by Enrico Stahn [ 01/Sep/10 ]

Proposal for a solution: http://github.com/estahn/doctrine1/compare/master...DC-852

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

So if you enable this attribute you live with the fact that casting a string to an integer that is longer than php max integer will give weird results?

Comment by Enrico Stahn [ 02/Sep/10 ]

i'm far from happy with this solution. if an integer that is greater than php max int gets casted it will be casted into a value of type double. if you enable that attribute only values that could successfully casted into an integer will be casted otherwise an exception will be thrown.





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





Generated at Wed Jul 30 13:09:35 UTC 2014 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.