Patch for HyperDB

Hi !

Thank you for the patch !

I just tried it and it makes sense. We will run a few more tests and it will available in the next version of the plugin (probably within two weeks).

Best regards,

Pierre D.

Hi Pierre,

Two thoughts about HyperDB:

HyperDB supports using several database servers. This patch doesn’t address that. To add support for that case would require a lot of changes and, as long as I don’t need it, I haven’t worked on it.

So this patch adds partial support for HyperDB: when there are several databases in the same database server.

Best wishes,

Toni

Hi Toni,

I just released the new version, with several bugfixs, and your patch.

Thank you for the thoughts. I was aware of that, and as soon a I can, I will try to work on HyperDB and understand how exactly multi-db is working. If you work on it, feel free to help us !

I think we could at least come up with well thinked hooks that would permit to do the appropriate actions to change the target database when needed.

But you’re right, a complete support for HyperDB multi-database mode would require a lot of changes, maybe on the GUI too (something to choose the target DB when duplicating a site, if HyperDB is active ?).

Best regards,

Pierre

Hi Pierre,

Sorry for the late response. I really don’t have time to work on this…

I tried to understand how does HyperDB works, but I was unsuccessful. I even tried to examine the binary log of MySQL to reproduce the steps that it does, but I suppose that not everything is logged.

HyperDB introduces a transparent layer in WordPress that “magically” connects to the correct database when someone accesses a blog. Of course it’s not magic, but that’s the point: find out the algorism in the HyperDB code, which is not so simple as it may appear. I couldn’t find it. ??

One possible approach is as described above: do the same that HyperDB does. But another possibility to explore is allow HyperDB to do the work:

HyperDB defines a class called hyperdb that extends wpdb. After that, instead of using the original wpdb, it creates an instance of the extended class, with the same name, that replaces the original. From that moment on, WordPress works with wpdb as usual and everything is fine.

So, the second approach could be to behave as WordPress and let HyperDB connect to the correct server and database. I must say that I don’t know how to do it. I’m even not sure that it is possible! ??

Best wishes,

Toni

Hi Toni !

I think the patch for HyperDB caused a few problems, and at the end, I removed it for release 1.3.0

The line that selected the table schema was wrong because it could select any schema with same tables than the one we want to copy :

$sql_query = $wpdb->prepare('SELECT TABLE_SCHEMA FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME = \'%s\'', $table);
$schema = MUCD_Data::do_sql_query($sql_query, 'var');

In a DB with several WP installations and same prefixes, it caused the plugin to duplicate wrong sites.

I failed to find how to fix this bug and keep HyperDB compatibility, this is why i removed it for now.

If you have time to work on a solution, I’ll be glad to get back HyperDB partial compatibility ??

Feel free to fork the plugin on github. We could create a branch for HyperDB compatibility issues.

Bests regards,

Pierre

Hi Pierre,

Yes, you’re right: In the information schema there are references to all the tables in the server and it is a problem in some cases.

I had a look at it and I think we can take advantage of the fact that the latest blog accessed before the copy is the original blog, so we can get the data base this way:

$schema = $wpdb->last_used_server[‘name’];

So you can change this line:

$sql_query = $wpdb->prepare(‘SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME LIKE \’%s\”, $like . ‘%’);

by this two:

$schema = $wpdb->last_used_server[‘name’];
$sql_query = $wpdb->prepare(‘SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME LIKE \’%s\’ AND TABLE_SCHEMA = \’%s\”, $like . ‘%’, $schema);

A consequence of that is that you can remove the lines 63 and 64, because we already know the data base:

// $sql_query = $wpdb->prepare(‘SELECT TABLE_SCHEMA FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME = \’%s\”, $table);
// $schema = MUCD_Data::do_sql_query($sql_query, ‘var’);

Those changes worked for me in my development environment, using HyperDB, but the code should be tested without HyperDB. Anyway, it should work because it doesn’t rely on HyperDB but in WordPress itself.

All the best,

Toni