On 10 Aug 2008, at 9:18 AM, Greg Dunlap wrote:
This whole problem would be much simpler if every "thing" had a GUID. Get that in place, and building a system to do deployment in the way described above actually becomes a realistic proposition. As Sam implied I've been conceptualizing a solution based on this premise, but its been hard finding time to really work on it. Hopefully soon.
We could create an object table pretty simply, and just keep that maintained, with the object type, object area (ie: production, staging, etc) and reference id. And could then just write drivers for each of the object types. Most of the 'drivers' would be really simple, ie; just wrapping node_load and node_save or drupal_execute. We could make it a lot simpler to support the object table by writing a very simple fapi submit handler that gets added onto forms that need to be indexed in the oid table : $form['#submit']['drupal_object_register'] = array('node', 'nid', 'area'); // just tells it to use $form_values['nid'] and $form_values['area'] when sticking it in the table. We would also be able to handle versioning, although the idea of tracking node revisions like this on a busy site with revision tracking could get difficult. Add a datestamp on there, and you could have the proper order to import objects too.