Which table to Prefix

I thought about putting table creation restrictions in place, but decided against it because people need to experiment and test.

Here are some tables that I know will cause problems, if they are prefixed, because they will alter the expected behavior:

{node *} -- that is, any table like {node} or {node_access}
{system}
{variable}
{comments} -- possibly, since these are tied to nodes
{domain *} -- which actually is restricted by the module
{files}
{file_revisions}
{content *} -- CCK tables
{search_*} -- unless you want to try to keep search separate for all domains.

As for restricting modules, I consider that out of scope. But it was raised over here today as well: http://drupal.org/node/282488

For more information, see http://drupal.org/node/2622.

I realize that this thread has been closed for quite some time, but I was hoping I may be able to get a bit more clarification on a point you made here. I understand why most of the tables you discussed could cause potential problems, but I was curious what exactly would constitute "altered expected behavior" when prefixing the system table?

I see in a few other issue discussions that this same sentiment was repeated. But without any additional explanation.

Obviously issues could arise if someone tried to disable the domain access modules on some of the sub domains. Or perhaps if someone tried to disable necessary modules for say a particular content type. (For example, the cck number module.) This would of course cause that content type (assuming that all node related tables are shared) to stop working correctly on all domains/sub-domains.

Besides these kinds of possible issues.... are there any others that stand out? I am a total newbee when it comes to the domain access module and am simply trying to get my mind wrapped around how it works and its strengths/weaknesses.

Just to help clarify why I am asking.... I am working on a project in which module bloat is becoming a bit of an issue. (Which many people can relate too, I'm sure.) And I have come across a few articles suggesting splitting your site across multiple sub-domains in order to reduce the number of modules active on any given domain. (Assuming that the setup even lends itself to such an approach.)

So I just figured I would see if something along this line would/could work with the domain access module. Any suggestions/pointers/words of caution would be GREATLY appreciated.

And Thanks for making such an amazing module to begin with!

You have neatly summarized the problem. If you aren't careful with prefixed {system} tables, then some features may "go missing" on some sites.

The bigger problem is more complex and can't be documented generically. Let's take this example:

1) You have 4 sites, and prefix the {system} table to disable some modules.

2) You do not prefix any other tables.

3) You have the foo.module, which updates the {foo} table whenever a node is saved.

4) Nodes are shared across one {node} table.

5) Foo module is active on domains 1 and 2, but not 3 and 4,

6) You create a node on domain 1, and it is entered in {foo} table.

7) You edit that node on domain 4 (or delete it), and {foo} table is not updated.

8) Your data is now wrong.

This is even _more_ complicated in Drupal 7, which has a function / hook registry. That means that hooks defined by foo.module may not be registered correctly unless you also prefix the {registry} table.

In general, prefixing {system} is a bad idea. With the concerns you cite, you may want to move to traditional Multi-site and abandon Domain Access.

Thank you agentrickard, your comments were quite helpful.... they clarified a number of different things (especially with Drupal 7) that I had not previously thought of.

Thank you again for the assist....