On Sunday 10 August 2008 08:17:15 Victor Kane 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.
Just a quick point on this: if every "thing" had a GUID (that is, a globally unique identifier (PHP's uniqid is sufficient if it the prefix parameter is invoked in order to identify the host machine's MAC, mayble butressed with an addional field based on an aleatory number, since otherwise duplicate timestamp based id's will be created), AND if every "thing" were serializable / unserializable (and here we mustn't forget certain encoding problems). Serializable: take an in memory object and turn it into a text object that can be stored in a file, version controlled, deployed via unserialization, etc.). Then you would have a realistic proposition.
Certainly achievable for nodes, perhaps lots of other stuff, but I don't know if every "thing" in Drupal required for deployment, site merging, etc.
Just wanted to extende thoughts in that direction.
So if I've missed this in your/others' thoughts Victor, please forgive me, but...why are we talking about serializing and unserializing data? As you pointed out in your first email:
There is no straightforward way in Drupal to export and import a given content type's nodes.
No off-the-shelf, simple way of doing it.
I agree. So...why talk about it at all? Deploy uses that approach at present, but we needn't be wedded to it. It seems to me that the GUID-based system is the thinnest possible way of allowing Deploy to keep track of the fact that "Thing A" on server 1 is "Thing B" on server 2. Deploy's API shouldn't be aware of what the Things are - just that they need to be checked against each other. And then it's up to the module(s) that created (or altered) the Things to decide what data comprises them, how to check that data against each other on the servers, and then how to resolve differences. The two biggest problems with that are handling data changes which have dependency chains (node system type changes being the most obvious) and that it could potentially make for an API too complex for general consumption. But that seems less insurmountable to me than the import/export problem. Unless I've missed something? Sam