[development] Solving the dev->staging->live problem

[Victor Kane]

The serialization and unserialization of data is included in my
approach to the problem for the purposes of the independent
transmission of nodes from one system to another, as in the case of
one Drupal site availing itself of a node.save service on another
Drupal site.

It also has the purpose of guaranteeing insofar as is possible a text
version of all entities, configurations, including exported views,
content types, panels, hopefully menues and module configurations and
exported variables, for the purposes of continued version control and
hence deployment also (serialization to text, unserialization to
deployment objective).

Here of course, serialization and unserialization is not meant in the
php function sense, and could include marshaling and unmarshaling to
and from XML, and is a cross-language concept.

Victor Kane
http://awebfactory.com.ar

On Sun, Aug 10, 2008 at 8:32 PM, Sam Boyer <drupal at samboyer.org> wrote:
> 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
>
>
>