How to merge Drupal database changes

views:

522

answers:

+4 Q:

How to merge Drupal database changes

We currently use an SVN repository to ensure everyone's local environments are kept up-to-date. However, Drupal website development is somewhat trickier in that any custom code you write (for instance, PHP code written for a node body) is stored in the DB and the changes aren't recognized by the SVN working copy.

There are a couple of developers who are presently working on the same area of a Drupal site, but we're uncertain about how to best merge our local Drupal database changes together. Committing patches of database dumps seem clumsy at best and is most likely inefficient and error-prone for this purpose.

Any suggestions about how to approach this issue is appreciated!

+1 A:

By committing patches of database dumps, do you mean taking an entire extract of the db and committing it after each change?

How about a master copy of the database? Extract all tables, views, sps, etc... into individual files, put them into svn and do your merge edits on the individual objects?

Steve 2009-10-09 18:58:25

Yep, meant taking entire extract of the database. The output of this dump file really depends on how the developer specifies the output arguments (some may request DROP IF EXISTS statements, or comments to be included, for instance), so this isn't very reliable.Extracting every table seems a bit too tedious for what it's worth and comes with the same inconsistency issues.

David 2009-10-09 19:11:05

I would standardize how you extract scripts - eg, always have drop if exists and permission statements, standard formatting. Also, if you have your objects individually scripted out, and devs commit all objects related to a change in one commit, it becomes more manageable. I'm assuming when you're committing and doing your resolves, you're looking through a big file and doing alot of scrolling. When you're working with individual files, this forces your focus on one thing. You only need to extract everything once, at the last working production state and work from there.

Steve 2009-10-09 19:52:49

+2 A:

If you are putting php code into your database then you are doing it wrong. Some stuff are inside the database like views and cck fields plus some settings. But if you put php code inside the node body you are creating a big code maintenance problem. You should really use the API and hooks instead. Create modules instead of ugly hacks with eval etc.

googletorp 2009-10-09 20:44:00

Good suggestion, thanks. However, this still leaves the question open as to how you would merge other database changes that developers make to their local environments (such as adding CCK fields or node settings) before the whole thing goes live on a central database. Custom PHP code is one of the few input types built into Drupal (granted you can disable it in Drupal 6), which suggests that it is a more flexible feature of this CMS than an ugly hack.

David 2009-10-09 21:09:26

It exists for quick and dirty work, but is generally regarded as a bad idea- all eval'd code is to be avoided. The problem you are facing is a perfect case in point. It is a good feature- it's good for quick experiments and building CCK/Views you know you will export and run as flat file code.

Grayside 2009-10-09 23:38:03

+3 A:

Unfortunately, database deployment/update is one of Drupals weak spots. See this question & answers as well as this one for some suggestions on how to deal with it.

As for CCK, you could find some hints here.

As for php code in content, I agree with googletorp in that you should avoid doing this. However, if for some reason you absolutely have to do it, you could try to reduce the code to a simple function call. Thus you'd have the function itself in a module (and this would be tracked via SVN). But then you are only a little step from removing the need for the inline code anyways ...

Henrik Opel 2009-10-09 21:52:51

ansaurus

tags:

views:

answers:

How to merge Drupal database changes

related questions