[support] WAS Why .. now 3 ways to save the db which is best

[Metzler, David]

This is the best strategy by far; either a positive list or list of
excluded tables in a using a dump option. Since you're just ramping
though, I'd wait to you got a little more experience about what's data
and what's not in drupal before you get to worried beyond a backup of
the site.   

What we typically do is export from production back to test/dev on a
periodic basis to make sure that CODE we write works against production
database.  Version controlling drupal configuration data is pretty heady
stuff, requiring intimate knowledge of the data structures used in your
site. 

I beg to disagree about SQL... it's much more than an API, but a
programming language.  It isn't well used in drupal, but is quite
powerful as a language in its own right.  It's set based, so there's a
learning curve to use it well.  There are things that take tons of work
to do in PHP that can be done easily in SQL.   

That being said, SQL is easily versioned and most of that in drupal is
in .module or .install files already.  It's only when the configuration
lines get blurred that you have to start worrying about what's code and
what's data.   That's no different for images and media files on the
file system than it is for the data that's in the dbms. 

-----Original Message-----
From: support-bounces at drupal.org [mailto:support-bounces at drupal.org] On
Behalf Of Roman Zimmermann
Sent: Wednesday, July 13, 2011 1:29 PM
To: support at drupal.org
Subject: Re: [support] WAS Why .. now 3 ways to save the db which is
best


It is still possible to use database dumps to do some sort of version
control for the database. The "ever changing" data is located only in
some tables. Most of them are caches or session tables that can be
truncated without further consequences. So you can make a dump of the
database that excludes the data (=rows) from certain tables. This dump
will be (nearly) constant as long as the configuration doesn't change
and no content is added.

"drush sql-dump --ordered-dump" together with a good list of
structure-tables would do the trick - with one exception that is
mentioned here: http://drupal.org/node/1132238

roman
-- 
[ Drupal support list | http://lists.drupal.org/ ]