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

[Ernst Plüss]

2008/8/10 Adrian Rossouw <adrian at bryght.com>

>
> On 10 Aug 2008, at 3:19 PM, Ernst Plüss wrote:
>
> With the help of a GUID and a timestamp of the last write access in every
> table it would be easy to synchronize Databases. If you want to synchronize
> only certain elements like varialbes, nodes, users, configuration etc.
> modules could provide a hook which
>
> Not all tables have timestamps, and it would require adding a whole mess of
> extra columns.
>


Adding Timestamp columns would not be to hard. For MySql you don't even have
to change the module code since the DB does everything for you. Up on every
write operation a new timestamp is set automatically.
The GUID would be a little bit harder. AFAIK there's no automatic insertin
of GUIDs for primary keys. But the functionality could be integrated in the
db_xyz functions.



   - just lists the db table to snychronize
   - gets the result of db compaire and let the user decide what will be
   pushed to the other side.

That's a lot of functionality, considering the weird merging of tables, and
> additional foreign keys. Take for examplea simple single -> multi
> relationship. You'd have to compare the bunch of them, and understand how to
> generate them all.
>

For new and updated rows it's actually very easy. First check for the
timestamp. Then check for the GUID. If it's there update the row from the
source db if not insert it. This works always and is not dependant on the
relationships between the tables.
The hard things are the deleted rows. You have to check for every GUID in
the destination db whether it still exists in the source db. If you have a
lot of data this can take a some time.

The hook is meant as a help for modul developers in case you don't want to
migrate a whole db but you let's say a certain node type. So you can do some
filtering or what every makes sense.



> All this stuff is already in most of the _load functions. It's also a LOT
> easier to compare 2 objects to each other
> (take the diff module for instance).
>
> Also, the db updates then get related  very directly to the schema the
> modules export.
>
> Both things could be handled by the db_query() function, to make sure no
> one forgets to touch the access timestamp and creates accurate GUID's.
>
>
> I think that perhaps db_query is too low a level for this, as that would
> add extra cycles on every single query done to the database, and probably
> also parsing the query (or changing all the db_query calls in core with
> extra parameters).
>
> And it's also not that hard to make sure the access stamp isn't changed,
> and is only related to nodes.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20080810/5295499e/attachment.htm