On Tue, Aug 12, 2008 at 1:33 PM, Dave Cohen <drupal@dave-cohen.com> wrote:
<snip> While in your model as I understand it, I now have some variables (configuration, of the access control module) referring to my term ids (content). So the line is crossed, I can't replicate the configuration unless I also replicate the content. If I understand you correctly.
I say this trying to point out that we can't simply divide Drupal's database into "content" tables and "configuration" tables. Unfortunately is will never be that simple. There are many examples like this where the line between content and configuration is fuzzy.
Dave, you are correct. It is for this reason that I took the "merge" approach. I have been thinking very deeply about this topic for about a year now, so I may not so quickly 'get' everything that is being discussed as I'm likely in a rut in my thinking. However, I feel then my role may be best to at the very least provide what I have learned for those who do 'get' the whole issue. The way Drupal behaves, creating this fuzzy division between configuration and content, makes this whole process difficult. This is the core of the problem, otherwise we could just copy tables back and forth. As I see it, UUID's would really only solve one problem of the whole package - the sequences issue. It's, of course, a great problem to solve, however, there are other issues. One of the things that likely needs to be supported in any system is modifying content data in both development and production. I think it is a long ways off before this fuzzy division will go away. In all of the sites I have developed, I have in some way touched and modified nodes during development of a site that has a live counterpart. Your taxonomy example is great, as it can be both used for configuration (access control) and content (free tagging) on one website. Yikes. If you allow modification of content data on both development and production, then it opens a whole can of worms when merging that data. The biggest issue is figuring out what is "new" content and what is "deleted" content. If I delete something in development, is that deletion eliminated because it is considered "new" content from production? If I delete something in production, how do I push that back to development without development inadvertently pushing it back to production? Then, ick, what if the same piece of content is modified on both production and development (lets say the menus as the most likely culprit)? (please excuse me if this was a double post) --- Kathleen Murtagh