I think a really interesting project is the deploy module (http://drupal.org/project/deploy ) which I think is an interesting abstract approach to this issue. It won't meet everybody's needs, and isn't functionally sufficient yet (for content at least), but is a good start, and worth starting a more serious conversation of how this problem might be addressed from the larger Drupal community. Some of the concepts that Greg has already got in place are critical for the staging issue. You can check out a talk Greg did on the deploy module at the Seattle Drupal User Group here: http://blip.tv/file/1033300 Anyway, food for thought. a. On Aug 9, 2008, at 2:35 PM, Dave Cohen wrote:
Personally, I don't see how two DBs improves things. In my experience, nodes are often "configuration" as well as "content". Trying to draw that line somewhere is a mistake, IMHO. You might draw the line where it makes sense for your sites, but not someone elses.
As you point out, the list is highly debatable. I think it's undecidable.
-Dave
On Saturday 09 August 2008, Zohar Stolar wrote:
As yhager proposed, having two DBs instead of one, may ease things a lot. One DB will hold content: nodes, revisions, files, users... The second DB will hold configuration: views, cck structure, modules, variables... (this list is highly debatable).
This will allow for two-ways updating - content is pulled down, while configuration can be easily pushed up.
--------------------------------------------------- arthur@civicactions.com