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

[Andy Heath]

David and Roman - thankyou *both* for your very helpful suggestions.
I don't disagree on sql David - particularly if you are working at the 
analysis/design level. I *have* done sql work but most of it was 30 
years ago when it was just starting to compete with codasyl databases.

I like Roman's suggestion very much because it forces me to grapple with 
precisely the area you describe David - the relationship between the 
code and the data in drupal. I'm aiming to do some serious work with 
drupal particularly in accessibility (I've worked the last ten years in 
international accessibility technology standards - I edit a couple of 
them so I have to know my technology onions - drupal is a good vehicle 
to re-learn the php/sql ropes in a serious system again).

The test/dev/prod idea goes a long way yes, but in exploring code ideas, 
which is where I'm at/going, its incredibly useful to be able to version 
the whole thing - code+data - so as to be able to revert to some 
particular version reliably. So that's my next step - to explore 
precisely what *is* static and what isn't so I can drag out for some 
instance of the database some serialised form that is non-variant for 
that instance and can enable the database to be re-constructed. You have 
both helped me along that path, thankyou.

If it was easy it wouldn't be fun.

Roman - external configuration changing isn't an issue as I need to 
version those files too.  Hmmmm - could be tricky with some of this in 
the db tho. - we'll see. I've read the link you posted Roman and the 
patch and this is the kind of thing I was thinking towards. Again, 
thankyou to you both, I'll probably come back to you when I got a little 
further on the code-versus data thing in terms of what's where in the 
tables.

andy
> 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