Bug #3540
data-load fails if QubitRepository has entity_type_id
Status: | Won't fix | Start date: | ||
---|---|---|---|---|
Priority: | Low | Due 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 almost 12 years ago
- Priority set to Medium
[g] Labels added: Priority-Medium
#2 Updated by David Juhasz almost 12 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 12 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 over 11 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 over 11 years ago
- Assignee deleted (
Anonymous)
#6 Updated by David Juhasz over 11 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 over 11 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 over 11 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 over 11 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
#11 Updated by David Juhasz over 10 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 about 10 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.