yes. exactly. would like to have wp_options in VIP1
Can you get it done? My old DB is using wp_1_options. I know this WP 3.2 is using wp_options as default. I would like very much that this can be in VIP1 db
10635 pointsLike some sort of WPMU DEV GodMindblowingly helpful memberLifetime member
Sales & Support Lead
—
18th October 2011 (7 months ago)
#
Hiya hwong,
You're right. I don't see a way to do this at the moment. I'm going to move this to our 'feature request' area and alert the developer. He'll take a look and this way other members will be able to chime in if they'd like this added as well.
At the moment multi_db locates table names in your queries and then checks for a number in the table name, this identifies the blog_id and thus the database to use, or if there isn't a number then it assumes it's a global table and keeps that in the one place.
Adding the extra step would add in a extra parsing / checks for every query run on your system. We can check performance and viability, but we ideally want to keep the extra work the plugin does to a minimum as you have to multiply it by the number of queries performed for each page load and at some point it's going to start slowing things down.
Do you mean have more than one global database? That's pretty much the same as the answer I gave before:
Adding the extra step would add in a extra parsing / checks for every query run on your system. We can check performance and viability, but we ideally want to keep the extra work the plugin does to a minimum as you have to multiply it by the number of queries performed for each page load and at some point it's going to start slowing things down.
We'll look at it for the next update, but it will have to be based on performance more than nice-to-have. If we can't see a major performance issue with it, then we'll happily add it in but if it starts (or looks to be) causing a slowdown, then we'd rather keep things simple and fast.
Responses (9)
Member — 10th October 2011 (7 months ago) #
Can anyone fix this? at least let wp_options be in the VIP1 db
Hwong
WPMU DEV Fanatic — 10th October 2011 (7 months ago) #
Hi hwong,
Just to be sure I understand you correctly, you'd like to have wp_options reside in a VIP database instead of the global database, is that correct?
If so, I don't see how that would be possible given the way the plugin works. Could you let me know if that's what you're trying to achieve?
Thanks,
David
Member — 10th October 2011 (7 months ago) #
yes. exactly. would like to have wp_options in VIP1
Can you get it done? My old DB is using wp_1_options. I know this WP 3.2 is using wp_options as default. I would like very much that this can be in VIP1 db
How do you think it can be done?
Hwong
Member — 11th October 2011 (7 months ago) #
any feedback on this? can i use wp_options as vip1?
Sales & Support Lead — 18th October 2011 (7 months ago) #
Hiya hwong,
You're right. I don't see a way to do this at the moment. I'm going to move this to our 'feature request' area and alert the developer. He'll take a look and this way other members will be able to chime in if they'd like this added as well.
Thanks!
Developer — 19th October 2011 (7 months ago) #
At the moment multi_db locates table names in your queries and then checks for a number in the table name, this identifies the blog_id and thus the database to use, or if there isn't a number then it assumes it's a global table and keeps that in the one place.
Adding the extra step would add in a extra parsing / checks for every query run on your system. We can check performance and viability, but we ideally want to keep the extra work the plugin does to a minimum as you have to multiply it by the number of queries performed for each page load and at some point it's going to start slowing things down.
Member — 19th October 2011 (7 months ago) #
can we have add_global_table separate into a db itself?
e.g. global1 db
global2 db
e.g.
add_global1_table('wp_options');
add_global2_table('ust');
is this possible for the next upgrade? else how can it be done now?
Developer — 19th October 2011 (7 months ago) #
Do you mean have more than one global database? That's pretty much the same as the answer I gave before:
We'll look at it for the next update, but it will have to be based on performance more than nice-to-have. If we can't see a major performance issue with it, then we'll happily add it in but if it starts (or looks to be) causing a slowdown, then we'd rather keep things simple and fast.
Member — 20th October 2011 (7 months ago) #
i think the array for this extra table setting should not slow down the query that much. the bottleneck should always come from the db queried.
Become a member