Domain prefix should update sequence table

When using database prefixing, each table that uses the {sequences} table gets its own entry in the form 'tablename_variable' -- so I do not see why this is an issue.

Are you having actual problems?

I see -- here's the potential issue:

Sites: example.com and test.example.com

Tables for {views} created for both domains. We create some views in both, and get the following variables:

view_view_vid          4
domain_1_view_vid  2

Now this should not be an issue unless you select the "update" option. In that case, we copy the 4 views from example.com, but the sequence for test.example.com id is at 2, so if we create a new view on test.example.com, we would get an id error.

I suppose that during the 'update' sequence, we would have to go through the {sequences} table, find the items that are prefixed, and then copy their 'parent' elements over.

Note that this is not an issue in the D6 version, since {sequences} has been deprecated.

If anyone wants to try a patch, we would insert a function into this sequence, lines 555-566 of domain_prefix.module:

        else if ($value == DOMAIN_PREFIX_UPDATE) {
          if ($exists > 0) {
            db_query("TRUNCATE TABLE {%s}", $newtable);
            db_query("INSERT INTO {%s} SELECT * FROM {%s}", $newtable, $sourcetable);
            // New function to be written to update {sequences}
            domain_prefix_update_sequences($prefix);
            if ($msg) {
              drupal_set_message(t('!string table updated from source.', array('!string' => $newtable)));
            }
            $update = TRUE;
            // Set the stored value to "copy" for record keeping.
            $value = DOMAIN_PREFIX_COPY;
          }
        }

Hm. This is actually more complex than described above. We cannot simply update _all_ the matching sequences, since we don't always want to update every item associated with a domain.

But, there may not be an easy way to determine which variables are assigned to which tables without knowing the table name.

So:

            // New function to be written to update {sequences}
            domain_prefix_update_sequences($prefix, $newtable);

OK. We need to run this on both COPY and UPDATE. Working on the patch.

Patch addresses the COPY and UPDATE routines -- and on DELETE and UNINSTALL as well.

This patch is not quite right. We must use the $sourcetable and not assume the default table.

OK. This patch should work.

There is a way to account for that; I just overlooked it -- which is what patch testing is for. Thanks!

OK. Here's a new patch that should fix this issue.

I'd like to see a patch that addresses these issues.

Issue #1 needs more detail.

Prefixing the node tables is a very bad idea -- it would, in effect, break DA, since you split the node tables across multiple domains, then the node access rules would work unpredictably.

To ensure that we only prefix the proper table -- via string matching such as node_* catching node_revisions_* by accident -- we will have to parse the string using explode().

Using {%s} seems to be a good choice.

New patch for testing.

OK, when giving these reports, more detail would help. I think the issue to fix is the first one. Shortest match is not the proper solution.

"Doesn't work when the source table is not from primary domain."

But _what happens_ when you do that?

Here's another patch. Using a regex to strip out parts of the variable name that we don't want.

Nice. I may not ge a chance to test for a bit, though, since I am on the road.

Originally, I had the regex in order to be sure to strip all possible global $db_prefix strings and combinations of 'domain_#'.

We need a little more testing, I think.

Seems to work on both prefixed and non-prefixed databases. Committed.

Excellent work on this patch!