Nice work on this project! I'm digging into building an install profile using profiler to supplement what we don't get yet with features and I like what I see.
One thing I'd like to look at is references between items to be created. (This question is an issue in Features too.) Take for example users and nodes. Currently the code hard-codes UID values in creating a user and then in providing the UID of a node. This works, but isn't very robust. For example, it would break if another process first added a user.
We already have for each object a good identifier--the key it was given in the array where it was declared. For example, in profiler_example.profiler.inc, the 'superduper' user is explicitly assigned an ID, but could instead be identified as 'superduper'. I'd see this working as follows:
* user array remains the same except doesn't have the [uid] key.
* node array remains the same but in place of [uid] has:
nodes[front][_reference][property] = uid
nodes[front][_reference][type] = user
nodes[front][_referende][item] = superduper
To handle this we would need:
* track all objects that have been created in a static variable, noting the IDs that were assigned. E.g., for the superduper user, this would be:
$items['users']['superduper'] = 1;
* Iterate through all references, passing the array item by reference. If the references are already set, add their ID value to the passed array item, using the 'property'. E.g.,
nodes[front][_reference][property] = uid
nodes[front][_reference][type] = user
nodes[front][_reference][item] = superduper
becomes
nodes[front][uid] = 1
If they are not set, create the item and then set the ID property.
In some cases we would need to return a modified version of the ID value. For example, it should be possible to point menu items to specific nodes. For this:
menu-items[front][_reference][property] = link_path
menu-items[front][_reference][prefix] = node/
menu-items[front][_reference][type] = node
menu-items[front][_reference][item] = mynode
Comment | File | Size | Author |
---|---|---|---|
#2 | 818768-2-foreign-keys-profiler.patch | 8.04 KB | nedjo |
#2 | 818768-2-foreign-keys-profiler_example.patch | 2.58 KB | nedjo |
Comments
Comment #1
q0rban CreditAttribution: q0rban commentedHi! Yeah, this is definitely a problem, and your idea is a good one, however certain things—like uids and nids—seem so pervasive that it would be hard to account for every possible situation. Definitely open for patches. :)
Comment #2
nedjoHere's a rough draft of a patch, plus an accompanying update for profiler_example. I've limited it so far to handling nodes and users, but adding the rest would be straightforward. Did a quick test and it seemed something I did broke the skipping of the config screen on install (as a result of which there was a duplicate query to create the admin user), but the basic changes seemed to work--that is, the node was created with the correct user ID.
Some feedback at this point would be great (including any hints about what broke the install skipping). Does this look like the right approach? If so, I'll write the rest of the patch, including the rest of the object types in profiler_install.inc.
Comment #3
q0rban CreditAttribution: q0rban commentedHmm, I like this. Care to re-roll? Also, I'd like some other identifier than _reference. Maybe %reference% or... I don't know, open for ideas, I just don't really like the underscore at the beginning.
Comment #4
nedjoWe shd consider whether it would be better to use UUIDs.
Comment #5
nedjo