Last modified: 2010-05-15 16:03:46 UTC
Please see onto my page for more info too: http://meta.wikimedia.org/wiki/User:FireDragon ! Sorry for my bad english ! I have change the file '\includes\Database.php' at line 1003 to 1019 My new code is: <CODE> function tableName( $name ) { global $wgSharedDB; # Skip quoted literals if ( $name{0} != '`' ) { if ( isset( $wgSharedDB ) && 'user' == $name ) { $name = $wgSharedDB . $name; } else { if ( $this->mTablePrefix !== '' && strpos( '.', $name ) === false ) { $name = "{$this->mTablePrefix}$name"; } else { # Standard quoting $name = "`$name`"; } } } return $name; } </CODE> I have change the 'IF'- enquiry position and add a 'ELSE'. A example: I have install 2 wikis (local) with the prefix 'en_' and 'de_' Then I change the 'Database.php' with my code. In the 'LocalSettings.php' have change to: Sample code for the english mediawiki folder ! <CODE> $wgDBprefix = "en_"; $wgSharedDB = "de_"; </CODE> So you can now use many other mediawiki's folder with other language And the user must now! only one to register for all mediawiki's on the same server withe the same database name. I test it now on my webserver in the next time the at www.wikipage.de I use not the official mediawiki- software! I use the 'MediaWiki 1.5alpha1 +ENotif/EConfirm v3.27 +AutoLogin v1.1' from http://meta.wikimedia.org/wiki/Email_notification_%28documentation%29#Download Thats a very cool and good Extensions !!!
Created attachment 603 [details] patch implementig the proposed code (untested!) I have made the code proposed above into a patch against the current CVS HEAD. I have *not* tested this, so your milage may vary.
Test-Wiki for this patch, see at http://www.wikipage.de/en/index.php/User:FireDragon (english-page) and http://www.wikipage.de/de/index.php/User:FireDragon (german-page)
Created attachment 634 [details] patch v2 Hi. We're working on similar issue for Developer Mozilla Center (https://bugzilla.mozilla.org/show_bug.cgi?id=296085). I wrote a patch for MediaWiki 1.4.5, and it seems to work better than one attached here. The patch from this bug still has a bug with strpos('.',$name) - copare to http://pl.php.net/manual/en/function.strpos.php . Our patch also solves the issue with table prefixes. Can I ask for some kind of review or sth?
Halló! I was wondering why we could *not* lock the database for one of the 6 wikis at http://www.wikipage.de/en/index.php/Main_Page . I understand that the user table is shared and this could cause some problems. Please verify if the database can be locked for individual wikis. If so what would be the procedure? Regards Reinhardt [[user:gangleri]]
Created attachment 707 [details] patch v3 I updated the patch. There was a small bug which made unable adding someone to admins. Now its fixed.
Created attachment 759 [details] patch v.3 against the trunk This is the patch against the trunk.
FYI: This patch is widely used on developer.mozilla.org and it works ok.
Hallo! I would like to add a small note based on "history" as the test configuration for 6+2 languages was lost. Please check if you need to apply the patch *before* users log in / sign in to wikis newly added to the wiki group. What happened: There where test wikis using different LanguageXx.php as de en eo it ja ro and about 20 registred users. Then two new wikis fr and la where set up. The seccond user signing in to the new wikis (user id #2) from fr and la was not identical with user id #2 from the first wikis. User id #2 made some hundred edits. Then the patch was applied. This was resulting in the strange situation that user id #2 from the first group of wikis was the creator of the pages, had them on his watchlist etc. etc. Recommended workaround. No user should sign in before the (original / earlier) patch is applied to a newly added wiki. Sorry for not reporting this before. Best regards Reinhardt [[user:gangleri]]
Well. This functionality should be used with new wikis. For already existing wikis I wrote a migration patch - (https://bugzilla.mozilla.org/attachment.cgi?id=189544)
Created attachment 760 [details] patch ver 4 Patch for trunk with fixed whitespaces and var names.
Looks good except the user_newtalk bit which appears clearly incorrect. Newtalk is per-wiki, since talk pages are per-wiki. Is there some reason for that, or could it be cleaned up? Removing patch, need-review keywords.
no problem, I wasn't sure how it should be solved. Can we check in this patch (without user_newtalk) then?
Created attachment 1653 [details] patch against 1.6.5 patch updated to 1.6.5. It *has* review+, what blocks us from checking it in?
Doesn't appear to work (tried merging on trunk). I set: $wgSharedDB = "onefive"; (left $wgSharedDBPrefix null) Queries end up with bogus escaping like this: ... FROM ``onefive`.`user`` WHERE user_id = '1' LIMIT 1 which results in SQL errors.
investigating
Brion: can you give me steps to reproduce it? It works for me.
1) Merge patch on trunk 2) Leave all table prefixes blank as default 3) Set $wgSharedDB to "shareduser" 4) Try to log in kabooms like so: SELECT user_id FROM ``shareduser`.`user`` WHERE user_name = 'WikiSysop' LIMIT 1
Created attachment 1668 [details] patch against 1.6.5 v2 ouch! Thanks, I screwed last patch. It missed } else { statement. Fixed in this patch
Created attachment 1669 [details] patch against 1.6.5 v3 grr, removed debug value from DefaultSettings.php
This looks like it should work, though it'll be incompatible with existing use of a common table prefix for all databases. Might it be cleaner to let it use the default table index if $wgSharedDBPrefix isn't set?
I could really use the latest version of this patch in the trunk. It definitely makes sense to be able to support both a shared user database AND a shared user table. I could also use a shared user_groups table. However, once you've done 2, you might as well do all. Perhaps there is a need for a run-time hook that can change the table names based on global variables. This could be used for other tables, like interwiki, math, etc.
Created attachment 2112 [details] Allows you to define which tables are shared This patch trumps the current purpose of this patch by allowing you to explicitly define which tables are shared. It allows you to specify an optional prefix for the shared tables as well as an optional other database. It makes sense to share more than one table because there are multiple tables that could be shared between a wiki family. These include: user, user_groups, ip_blocks, math, interwiki, and possibly others.
The only difference between my patch and Gregory's is the ability to select tables to share. I'm not convinced if we really need this, but if we do I can review this patch. Brion: please, make up your mind, what do we want from this patch, I'll try to make sure we have it and let's get it into trunk, it lasts so long in the pre-checkin universe.
It needs to 1) work and 2) not break for our existing users who use this feature, such as Wikia.
To be honest, I never reviewed my patch, but I think it should work. It is small enough to debug easily. I can actually test it later today. Anyway, the current method ($wgSharedDB) is marked as EXPERIMENTAL. IMO, this could be deprecated and people shouldn't complain because they were using an EXPERIMENTAL feature. In reality, I know, I know... The transition from wgSharedDB to my patch just involves changing a variable in LocalSettings.php. Also, it would be possible to have my patch look for the presence of $wgSharedDB. If it is set, $wgSharedTables is automatically populated with 'user'. I still argue that we need the ability to share any table we want. Obviously, we would never share some tables, like page, etc, but you never know who has a usage case for sharing a table, especially when it comes to custom extensions. If you are opering multiple wikis outside of the same database, it really doesn't make any sense to have separate math, ip_block, and interwiki tables (at least in some cases).
Gregory: I do agree with you, the problem is how to handle it smoothly. I'll take a deeper look today, and try to come with some solution.
Created attachment 2119 [details] Share any table (against r15716) This is my previous patch except it will support users of the old method ($wgSharedDB) without any configuration changes. This patch is still untested.
Created attachment 2128 [details] Share any table (against r15716) Added forgotten ` ` around table names. I've tested this against 1.7.1 and it works fine. Currently sharing user, user_groups, interwiki, and math tables between two wikis ;)
I'm a little leery of this kind of magic: +if ($wgSharedDB && !$wgSharedTableDatabase) { + $wgSharedTables[] = 'user'; +} Configuration settings that change violate the principle of least surprise; while we have a few such settings already, I'd prefer not to add more if it can be avoided more simply. Perhaps it would be cleaner to just set $wgSharedTables = array( 'user' ) as the default, and continue using $wgSharedDB cleanly?
If we default $wgSharedTables to array('user'), how do we prevent false positives? if (in_array('user', $wgSharedTables) && !$wgSharedDB) ?? That is just as hacky. Since $wgSharedDB is still experimental, how about we just break it by doing the following in Setup.php: if (isset($GLOBALS['wgSharedDB'])) { throw new MWException('wgSharedDB is no longer supported. See $wgSharedTables.'); } Anybody upgrading his or her wiki will immediately know what the problem is. There can't be that many people actually using $wgSharedDB. Those who do probably have the resources to test upgrades before putting them in production.
Can you elaborate more on "false positives"? Where would they appear?
I fail to see how using the presence of a normal, existing, already used in production by the second-largest known MediaWiki user, configuration setting as a guard condition in the one function that would use it constitutes being "just as hacky" as silently changing the configuration settings based on the presence of another setting (which could be set by a user if register_globals is on given its removal from DefaultSettings.php, potentially breaking things interestingly).
I agree with Brion here. btw. Brion, who do you call second-largest MediaWiki user? :> On which position MDC is? ;)
OK, so we support wgSharedDB alongside wgSharedTables. I argue that putting code in Setup.php, as is the case with the current patch, is better than in tableNames() because code in Setup.php only gets executed once. It doesn't make sense to evaluate the same logic for every call of tableNames() when it could be done once. Perhaps we should also add a trigger_error(foo, E_NOTICE) if wgSharedDB is on, so we can warn people they are using a deprecated method. In some later release, wgSharedDB throws an exception. In an even later release it is removed altogether, along with the hackish Setup.php code. This satisfy everyone?
I'm lost. As far as I understood the issue, Brion asked you why do you want to do this: +if ($wgSharedDB && !$wgSharedTableDatabase) { + $wgSharedTables[] = 'user'; +} instead +$wgSharedTables = array('user'); And you are answering about modyfing code in tableNames() function...
If $wgSharedTables defaults to array('user'), every wiki powered by a source tree will have the user database shared by default, using the current patch. This is like setting $wgSharedDB = true in DefaultSettings.php, a departure from the status quo. $wgSharedTables should be an empty array by default. Perhaps the patch for Setup.php should be: +if ($wgSharedDB && !in_array('user', $wgSharedTables) { + $wgSharedTables[] = 'user'; +} Effectively reads: If using old method of sharing user table and we haven't been told to share the user table using new method, then share the user table. I answer about $wgSharedDB in tableNames() b/c if we are trying to deprecate its usage, we should isolate the variable to somewhere where it can easily be removed. Setup.php is that place. Being a part of logic in tableNames() is no place for a deprecated variable. It will be much easier to deprecate its functionality in Setup.php than revisit the logic in tableNames(). This is also contingent on deprecating $wgSharedDB. Even then, I still argue it is less hackish to have a configuration variable change in Setup.php than to support two configuration variables using more complex logic in tableNames() than a single variable would require. Supporting two variables in tableNames() slows things down. Would you rather compute something once per session, or at least once per query?
(In reply to comment #36) > If $wgSharedTables defaults to array('user'), every wiki powered by a source > tree will have the user database shared by default, using the current patch. > This is like setting $wgSharedDB = true in DefaultSettings.php, a departure from > the status quo. The status quo is that the list of tables to share is hardcoded as just "user". If this were changed from a hardcoded list to a changeable list, perhaps called $wgSharedTables, then it could be increased or decreased at the will of the site administrator. For all intents and purposes this setting *already exists* in the code, it's just hardcoded in a function. There is no reason to deprecate the usage of $wgSharedDB and I would not recommend doing so. You need both settings anyway, so why rename one of them when there's no reason to?
I don't see a problem here. We can check if wgSharedDB is empty or not. If it's not, then yes, by default we want to share 'user' table. If it's empty, then we don't want to share anything. 29 that I'm not sure why you want to deprecate wgSharedDB, and I'm not sure if we agreed on that, at least I don't see Brion's comment saying that. In fact Brion said in Comment 29 that he prefers (as well as I do) to keep wgSharedDB and use the $wgSharedTables = array('user'); method. Could you please, explain once more why do you want to deprecate it?
In response to #37 and #38, the reason to deprecate wgSharedDB is because wgSharedTables supercedes its functionality. wgSharedDB gives you control over 1 table. wgSharedTables gives you control of any. It is bad coding to have two configuration variables that do almost the same thing, especially when one variable covers the entire functionality of another. You can keep wgSharedDB if you want, but it shouldn't be used in logic anywhere in the code, except for where its functionality is swallowed up by the larger variable, wgSharedTables.
Er, no. $wgSharedDB indicates which database, if any, the shared tables are pulled from. Being empty means that the shared tables are used in the local database (which we can think of as meaning that they aren't shared, or that the sharing system is disabled, but it's all the same thing really). In your patch, $wgSharedTables is a list of which tables are shared. It does not perform the function of $wgSharedDB, nor does it replace it in any way. Rather, it replaces the hardcoded check for the 'user' table name with a customizable list. In fact, your patch renames $wgSharedDB to $wgSharedTableDatabase. This indicates to me that you do agree that its function is required. If you agree that it is a required function, then I'm left asking why you want to rename it?
Gregory: But I do not understand why do you want to substitute wgSharedDB with wgSharedTables... wgSharedTables is a list of tables that are shared with common DB. wgSharedDB is a name of database where those common tables are stored. You want to deprecate wgSharedDB and instead add $wgSharedTableDatabase which does exactly the same. I see no goal in it. In result we'll have 3 variables. One to decide which DB stores common tables, second to decide what prefix shared tables use, and third to decide which tables are shared. Maybe it would be simpler to create map them? Sth like: $wgSharedTables ( 'user' => 'dbname.foo_user' ,'foo2' => 'db2.prefix_foo2' ); This way: 1) We limit the amount of variables 2) We're flexible like hell, you can keep every table in different database and with different prefix :)
I like the mapping idea in #41. Concatenates everything down to one variable. Makes it much simpler. Lot more flexible too. I proposed renaming wgSharedDB to wgSharedTablePrefix b/c, although the variable names reflect the same thing, the behavior of the variable is not identical. wgSharedDB as it currently is coded says, "I want to share the user database. Here is the database where it is located." wgSharedTableDatabase as coded in my patch says, "If you are sharing tables, here is the database in which these shared tables can be found" wgSharedDB is explicitly tied to the user table in the current code. It doesn't sit right with me that this association is altered. The behavior of a configuration setting should be constant between releases. This is why I think it warrants a variable name change. That being said, wgSharedDB is *experimental* and should be used at one's own risk. Perhaps we *can* get away with altering this configuration setting's behavior. Also, there is a logic error in my Setup.php component of my patch. Should be something like, +if ($wgSharedDB) { + $wgSharedTableDatabase = $wgSharedDB; + + if (!in_array('user', $wgSharedTables)) { + $wgSharedTables[] = 'user' + } +} Of course, this doesn't matter, b/c the mapping proposal is infinitely better. When will I see a patch?
Brion: what do you think? The only think that make me not confident about my solution is that it requires you to name the database and prefix eachtime while in 99% of cases it'll be the same...
If the db and prefix is the same in 99% of the cases, then any wise programmer would just write: $prefix = 'mydb.myprefix'; $wgSharedTables = array( 'user' => $prefix . 'user', 'interwiki' => $prefix . 'interwiki', ... ); It is a small inconvenience for better flexibility.
Created attachment 2140 [details] Shared tables as array map (against r15780) Implements $wgSharedTables as an array that maps a table name to a the desired name. Deprecates wgSharedDB because this variable is no longer needed since there is no such thing as "one shared database." The map can actually map tables to multiple databases, if desired. In interest of continuity, if wgSharedDB is present and no map for the 'user' table is set, then 'user' is mapped to $wgSharedDB . $wgDBprefix . 'user', just like current behavior.
Can you also look to Bug 7247 ? It seems to be concerned with shared user table realizations.
Brion: please, comment this bug. We're ready with two competing approaches here, and I'm not sure which one do you prefer?
As I understand, all that should be necessary is to have a table prefix in $wgSharedPrefix which will be used on the user table when $wgSharedDB is in use. I'm not really sure what all this other stuff is for.
Brion: You should be able to share any arbitrary table between wikis. Shouldn't a wiki family be able to share the interwiki, math, and ip_blocks (and possibly other) tables without having to modify the core function in Database.php? On a personal note, I could really use this feature for Farmer (http://www.mediawiki.org/wiki/User:IndyGreg/Farmer). Bottom line is the current implementation restricts what 3rd party developers can accomplish. The most recent patch fixes this.
Brion: as Gregory stated, we came up to the point where we propose something more flexible than what you say. In our approach you can select which tables you want to share. There's no difference for most users, because by default it only shares user table. The real difference is for anyone who's willing to share other tables between two mediawiki's or even store some tables in different location. Old approach made it impossible, while the new one requires only to add a new table_name=>db/prefix/tablename map to the array. Do you find this an overkill and would prefer to get rid of this?
using version 1.8.2. In order to use $wgSharedDB with one single database and prefixes, I had to change the following line in Database.php, in function tableName: if ( isset( $wgSharedDB ) && "{$this->mTablePrefix}user" == $name ) { $name = "`$wgSharedDB`.`$name`"; was changed to if ( isset( $wgSharedDB ) && "{$this->mTablePrefix}user" == $name ) { $name = "`$wgSharedDB`.user"; brion's answer to that is that he does not recommend using a prefix. I would argue that you guys should not write code using a mTablePrefix variable, if you assume that that variable is "". unless you have a sadistic personality.
I am a novice interested party who is trying to share a user table, not between wikis, but between mediawiki and another application. Using your suggestions above, I have pointed mediawiki to the user table I want to make the common one, but, because the username and password field names are different and mediawiki requires additional mediawiki-specific fields in the user table, it won't work. From the point of view of development, it seems that to make the functionality truly general, the patch will need to do several things: 1. allow administrators to map database_X.table_Y to database_W.table_Z, and 2. allow administrators to map from one field to another, and 3. automatically generate the mediawiki fields in the specified shared user table (other than the ones already mapped, e.g. username and password), if that is a user table from another application. So, as part of the setup, then, you could specify the user table, and then be allowed to map the appropriate fields, while setup goes on to add the rest of the necessary fields to the user table. I apologise for butting in where I can't really help at all, but it does seem that people will increasingly want to integrate mediawiki with other applications, and that the kind of thing I've outlined is what will be necessary in order for that to happen.
(In reply to comment #53) > I am a novice interested party who is trying to share a user table, not between > wikis, but between mediawiki and another application. Right, so stop here. $wgSharedDB is for sharing databases between MediaWiki installations. To instruct MediaWiki to authenticate against an external database, e.g. forum packages, LDAP, etc. either write or find and install an appropriate authentication plugin ("AuthPlugin"). You should be able to find quite a bit of information on this via a normal web search.
Thanks for that. Sorry to bother you guys. I'll have a hunt around.
*** Bug 9695 has been marked as a duplicate of this bug. ***
Created attachment 3610 [details] Gregory's patch updated to tip I've updated Gregory's patch to tip. It works very well. Brion: can you support us with your point of view? You stated your questions and I tried to answer them. How valuable you found it?
Created attachment 4101 [details] update to trunk to fix usage of $wgSharedDB. This fixes a bug in trunk, for how $wgSharedDB is used (at least, by my understanding of a sane interaction with a prefix (or lack thereof)). It looks like Gregory's patch is more comprehensive, but if you want to make a quick bug fix in the meantime, you can apply my patch. It is consistent with the recipe I describe here: http://wiki.johnjosephbachir.org/Multiple_MediaWiki_instances_sharing_a_codebase_and_user_table
I've done some testing: http://tablename.dev.wiki-tools.com/ I've compared various new types of tableName methods: * original is the current implementation. * gregory is the suggested and tweaked patch here. * rewrite is an old rewrite of tableName I had made. I never proposed this one anywhere because I hadn't tested it enough anywhere. But this test shows that it is working perfectly fine as expected (Well actually, I had to reverse a condition because I did something wrong in the original but it's fully functional now) * And rewrite2 is my new proposal. It's basically a modified version of the rewrite made to support a map similar to gregory's. The specifics of rewrite and primarily rewrite2 are: * $wgSharedDB is still used, additionally there is a $wgSharedPrefix variable that can be set with the prefix to use for the shared database. * $wgSharedTables is a array listing tables to be shared. If any table shows up in this list then the database used will be changed. * $wgTableMap is a table mapping, for the most part it's simply equivalent to gregory's setup. * Just for the hell of it I added a array cache. I can remove it if people don't like it, but there is little reason to go and run the same set of actions over and over when people ask for table names, so I just added it in. * Just as a side effect there's a new format for input allowed. Normally we only allow "table" and as an override "`database`.`table`" to stop things from being done. There isn't much reason for it but you can use the format "database.table" and table will automatically get the current prefix. There isn't much use for it, but don't worry about anything breaking, currently if you try and do that you'll end up with "`database.table`" which breaks horribly. One of the primary reasons I questioned it's compatibility was because I used a completely different method from the original. Instead of being ugly and testing things using the prefix over and over. I separate the name into it's database and table forms then take actions on the individual parts, and in the end combine them back together. A bit more elegant. Oh... Right now there is one thing it's doing which I don't know if I should change: When using the format "database.table" if table is set in $wgSharedTables then database will be overridden with the shared database. If you want, I can tweak it to honor the fact that the person asking for the table name explicitly gave a database name to use and expects it return that with the current prefix added. Also, I honestly don't like the ability to change the actual name of the database. Basically redirecting revisions to page is possible, even by accident, and there is no valid reason to change the name of a table like that. Honestly, I'd like to change the way $wgTableMap works and define it as a database/prefix pair integrating it into the actual splitting and merging of the name. The reason I'm using both a shared db config and a map is because I don't consider specifying individual locations for tables to be a very ideal way of configuring things when all you want is to share a set of tables with another wiki. But there is merit to allowing a different database/prefix for a certain table. I'll try and have brion take a look at it when he gets back... If it's good I'll commit it to trunk, and if it works perfectly fine everywhere hopefully it can end up in 1.12 so wiki can make use of it (Wikia wanted to use the other version I committed to trunk, hate to have them add another hack to their setup). Any notes or tweaks you want and I'll change the rewrite.
I'm pretty sure that these requirements should be sufficient for all sane uses: * specify a single target database name + prefix for all shared tables * specify the set of tables which are shared
Well... Actually, I can understand a sane use of a alternate table map: $wgSharedDB set to a shared database for: * users * RegexBlock * SpamRegex And at the same time, they may want to share an interwiki table. However they want the interwiki table to be shared from their commons wiki rather than their shared database. Or, there may be tri+ wiki sets where they only want a few tables shared, but those may be from one of the wiki, not others. Kinda complicated chain to visualize. A wants table1 from B, B wants table2 from C, and C wants table3 from A.
Ok, I rewrote tableName and brion okayed a final version. This has been fixed as of r34353. The new variables are $wgSharedPrefix and $wgSharedTables. The shared tables is only a list, not a map. Wanting to map tables rather than put them in a single shared database is a different bug. If there is a real good reason to have one a new bug should be opened to discuss it.
