Bug #3540

data-load fails if QubitRepository has entity_type_id

Added by Anonymous about 10 years ago. Updated over 7 years ago.

Status:Won't fixStart date:
Priority:LowDue date:
Assignee:-% Done:

0%

Category:-
Target version:Release 1.3
Google Code Legacy ID:atom-1590 Tested version:
Sponsored: Requires documentation:

Description

Google user: jack.bates

For example if a QubitRepository has an entity_type_id (defined by QubitActor) then presumably it fails to look up the value in the QubitTerm array

[g] Legacy categories: Migration task, Data model / ORM

History

#1 Updated by Anonymous about 10 years ago

  • Priority set to Medium

[g] Labels added: Priority-Medium

#2 Updated by David Juhasz about 10 years ago

  • Priority changed from Medium to High

[g] Labels added: Priority-High, Component-Migrations, Component-ORM-Data-Model
[g] Labels removed: Priority-Medium

#3 Updated by Jesús García Crespo almost 10 years ago

It seems that data-dump saves classes in the wrong order. Shouldn't term objects be written before information objects?

I used this code to fix it here (not sure if it is a good solution):

Index: symfony/lib/plugins/sfPropelPlugin/lib/addon/sfPropelData.class.php ===================================================================
--- symfony/lib/plugins/sfPropelPlugin/lib/addon/sfPropelData.class.php (r7471)
+++ symfony/lib/plugins/sfPropelPlugin/lib/addon/sfPropelData.class.php (working copy)
@ -326,7 +326,8 @
$classNames = array();

$dumpData = array();
-$dumpData['QubitTaxonomy'] = array();
+ $dumpData['QubitTaxonomy'] = array();
+ $dumpData['QubitTerm'] = array();
$tables = $this->fixOrderingOfForeignKeyData($tables);
foreach ($tables as $tableName)

#4 Updated by Jesús García Crespo almost 10 years ago

I don't know why but my suggested patch isn't working now, objects are not being saved in the correct order so data-load isn't working properly. I guess that this is not going to happen too much because the migration task set the order of objects correctly in the yaml data dump; then looks like this only would affect users that migrate data sets using YAML instead of SQL?

#5 Updated by Evelyn McLellan almost 10 years ago

  • Assignee deleted (Anonymous)

#6 Updated by David Juhasz almost 10 years ago

  • Status changed from New to New
  • Priority changed from High to Medium
  • Target version changed from Release 1.1 to Release 1.2

As far as I can tell a repository should never have an entity_type_id... IN any case it sounds like the migration script should fix the problem?

[g] Labels added: Milestone-Release-1.2, Priority-Medium
[g] Labels removed: Milestone-Release-1.1, Priority-High

#7 Updated by Jesús García Crespo almost 10 years ago

I think that Jack meant "type" field, those terms in QubitTaxonomy::REPOSITORY_TYPE_ID linked to the object with QubitObjectTermRelation. If you have a data set where there is at least one repository with one type set, these two procedures would fail:

1)
(a) php symfony propel:data-dump > dump.yml
(b) php symfony propel:data-load dump.yml

2)
(a) php symfony propel:data-dump > dump.yml
(b) php symfony propel:migrate dump.yml
(c) php symfony propel:data-load migrated_file.yml

#8 Updated by Jesús García Crespo almost 10 years ago

Actually, I have just realized that you don't need to set a type. Follow these steps to reproduce this issue:

1) Fresh install
2) Create a new blank repository
3) data-dump
4) data-load

Unable to execute INSERT statement. SQL: "INSERT INTO actor (`ID`,`PARENT_ID`,`LFT`,`RGT`,`SOURCE_CULTURE`) VALUES (:p1,:p2,:p3,:p4,:p5)" (actor.ID => '278', actor.PARENT_ID => 'QubitActor_3', actor.LFT => '5', actor.RGT => '6', actor.SOURCE_CULTURE => 'en') [wrapped: SQLSTATE23000: Integrity constraint violation: 1452 Cannot add or update a child row: a foreign key constraint fails (`qubit`.`actor`, CONSTRAINT `actor_FK_5` FOREIGN KEY (`parent_id`) REFERENCES `actor` (`id`))]

I am trying to figure out why "QubitActor_3" isn't being translated to its id value.

#9 Updated by David Juhasz almost 10 years ago

For (1):
The data-dump > data-load has been broken for qubit as long as I can remember, mostly because the order that objects is dumped doesn't respect foreign key requirements. (e.g QubitTerm should dump before QubitInformationObject, and parent should dump before for child). I don't think that making this work should be priority.

For (2):
I added a migration task to migrate the type_id column to a many-to-many key in r4827 [1]

[1] => http://code.google.com/p/qubit-toolkit/source/detail?r=4827

#10 Updated by David Juhasz about 9 years ago

  • Priority set to Low

[g] Labels added: Priority-Low

#11 Updated by David Juhasz over 8 years ago

  • Target version set to Release 1.3

Roll over to Release 1.3

[g] Labels added: Milestone-Release-1.3

#12 Updated by David Juhasz over 8 years ago

  • Status changed from New to Won't fix

Marking issue "WontFix".

The data-load task should not be used for database backup and restore, and we have updated the http://www.qubit-toolkit.org/wiki/index.php?title=Data_backup documentation to reflect this.

Going forward data-load task should only be used for data fixtures, where this is not an issue.

Also available in: Atom PDF