management of Prefixes for existing domains

I think you misunderstand the domain-specific prefix form.

Once you create prefix tables for a domain, you can drop them. You can also create new ones without destroying the existing ones.

The process is like this:

- Set up default domain settings.

- Enable automatic generation based on those settings.

- When new domains are created, prefixed tables will be made automatically.

- After the initial creation, you can use the domain-specific prefix form to create, copy, or drop additional tables.

So, in simple terms, you can submit the Prefix form multiple times for any domain record. What you can't do is Copy a table that has already been Created (and vice versa).

That said, the module isn't documented well yet and the UI may need some work.

Right. Copy and Create mean:

- Find the core (non-prefixed) version of the table(s)
- Create a duplicate table based on the structure of the core table.
- If specified, copy the data from the core table to the new table.

Create does not invoke hook_install() -- this should probably be documented.

It doesn't invoke that hook because:

-- Many of the core tables are in system.install, not module_name.install

-- hook_install() functions sometimes set system variables or insert data, and if you are not prefixing the variables table, for instance, some unwanted data may get loaded.

My assumption is that SchemaAPI in Drupal6 will make this process smoother.

Yes. And we will need some real-world user testing in order to document those 'recipes' correctly.

The good news is that creating / copying tables should not "break" your site irrevocably. The form submits from your primary domain, which cannot be prefixed, so you should be able to go back and undo (drop) any tables that cause issues.

I don't know, for example, if you need to copy over all the Taxonomy tables. It might be enough to create a new Vocabulary table and Forum table for each subdomain.

Not sure why you had to bring over comments as well, so documenting this will be crucial. The MultiSite group on g.d.o may help, and you might check the Handbooks for existing documentation.

I just know that we use this for Blocks, which requires copying three tables. It seems to work great, so I tried to extend the feature.

Additionally, some tables, like {sequences} and {system} should never be copied, and may end up on a banned list. Notice, for example, that you can't copy {domain} tables at all.