Hacker News new | ask | show | jobs
by fungi 5606 days ago
that's what we do in conjunction with http://drupal.org/project/features, bugs aside it works well

but what you want in code and what you want in the DB will vary from page to page and feature to feature so often just manually redo stuff (in dev env and then again in production) because deploying changes by code is more effort then its worth.
1 comments
georgecmu 5606 days ago
Managing the codebase is straightforward -- that's what git's designed for. My question was more about the actual site contents, which will reside in the database. Can you use git for tracking changes to the contents?
link
fungi 5606 days ago
> Managing the codebase is straightforward

not always, often stuff is stored in the db that we want to work on in dev then deploy to production.

but it would be nice to be able to export a selection of nodes to code and preserve there id's, content and metadata. maybe you'll find a features contrib mod http://drupal.org/taxonomy/term/11478 but i've never heard of one.

link
davegan 5606 days ago
No, git will not track database changes. Features however can handle much of the configuration (that is typically contained in the database) in code, which can then be managed with git.

If you want to create content on your dev or staging site and push it to production, check out the deploy module: http://drupal.org/project/deploy

Tracking changes to nodes in production is probably best left to Drupal's built in node versioning system. Diff (http://drupal.org/project/diff) is a handy module to track changes between revisions and if you want a little more advanced workflow check out revisioning (http://drupal.org/project/revisioning) and workflow (http://drupal.org/project/workflow). Good luck!

link
georgecmu 5606 days ago
Great info, thanks!
link
bricestacey 5606 days ago
Probably not. You're better off logging your MySQL queries and filtering out the UPDATE, INSERT, and DELETE queries for the tables you're interested in.
link
RobGR 5606 days ago
I would advise against that. There are too many places in he mess of tables of data configuration that might refer to specific auto-increment id columns were things will get out of sync. Basically you are trying to do MySQL replication on specific tables only, but there are too many relationships among all the tables.

If it is a small amount of content, such as a handful of pages for a brochure site, putting them in a feature might be best.

If it is a site where customers or visitors generate content on the site, then periodically re-initialize your dev and staging environments with copies of the live DB, running it through a script to anonymize all the user info and change passwords and etc.

If you want to create content on your dev and move it live, then doing a full database copy and moving it live, with settings that are particular to live overridden in settings.php, is probably the best way. I advise against this, basically you are re-launching the site for every change.

If you are truely desiring to be able to create content in multiple different places and move it to live, then probably the best thing to do explicitly program and configure for that, by specifying feeds of the content and setting up the different sites to ingest each other's feeds.

link
georgecmu 5606 days ago
FWIW, I found two takes on database versioning: http://www.gsdesign.ro/blog/mysql-database-versioning-strate... https://launchpad.net/dbvcs
link
georgecmu 5606 days ago
Interesting suggestion. Do you know if anyone is doing it this way?
link