Access to Memory (AtoM)

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)

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?

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

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: SQLSTATE²³⁰⁰⁰: 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.

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