Last modified: 2010-05-15 16:03:46 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T4396, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 2396 - PATCH: fix for shared user table with $wgSharedDB
PATCH: fix for shared user table with $wgSharedDB
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Database (Other open bugs)
1.13.x
All All
: Normal normal with 5 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
http://meta.wikimedia.org/wiki/User:F...
: crosswiki, patch
: 9695 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-06-12 20:34 UTC by FireDragon
Modified: 2010-05-15 16:03 UTC (History)
12 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
patch implementig the proposed code (untested!) (1.05 KB, patch)
2005-06-12 20:56 UTC, Daniel Kinzler
Details
patch v2 (2.33 KB, patch)
2005-06-22 14:57 UTC, Zbigniew Braniecki
Details
patch v3 (2.65 KB, patch)
2005-07-13 23:17 UTC, Zbigniew Braniecki
Details
patch v.3 against the trunk (2.01 KB, patch)
2005-08-03 17:06 UTC, Zbigniew Braniecki
Details
patch ver 4 (1.77 KB, patch)
2005-08-04 13:27 UTC, Zbigniew Braniecki
Details
patch against 1.6.5 (1.47 KB, patch)
2006-05-04 21:34 UTC, Zbigniew Braniecki
Details
patch against 1.6.5 v2 (1.51 KB, patch)
2006-05-06 01:07 UTC, Zbigniew Braniecki
Details
patch against 1.6.5 v3 (1.47 KB, patch)
2006-05-06 01:10 UTC, Zbigniew Braniecki
Details
Allows you to define which tables are shared (2.31 KB, patch)
2006-07-16 20:42 UTC, Gregory Szorc
Details
Share any table (against r15716) (2.92 KB, patch)
2006-07-18 02:53 UTC, Gregory Szorc
Details
Share any table (against r15716) (2.92 KB, patch)
2006-07-20 05:17 UTC, Gregory Szorc
Details
Shared tables as array map (against r15780) (3.44 KB, patch)
2006-07-22 17:51 UTC, Gregory Szorc
Details
Gregory's patch updated to tip (4.09 KB, patch)
2007-05-10 00:27 UTC, Zbigniew Braniecki
Details
update to trunk to fix usage of $wgSharedDB. (669 bytes, patch)
2007-09-12 07:58 UTC, John Joseph Bachir
Details

Description FireDragon 2005-06-12 20:34:26 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 !!!
Comment 1 Daniel Kinzler 2005-06-12 20:56:07 UTC
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.
Comment 2 FireDragon 2005-06-16 22:17:51 UTC
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)
Comment 3 Zbigniew Braniecki 2005-06-22 14:57:11 UTC
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?
Comment 4 lɛʁi לערי ריינהארט 2005-06-25 03:11:05 UTC
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]]
Comment 5 Zbigniew Braniecki 2005-07-13 23:17:00 UTC
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.
Comment 6 Zbigniew Braniecki 2005-08-03 17:06:22 UTC
Created attachment 759 [details]
patch v.3 against the trunk

This is the patch against the trunk.
Comment 7 Zbigniew Braniecki 2005-08-03 17:39:46 UTC
FYI: This patch is widely used on developer.mozilla.org and it works ok.
Comment 8 lɛʁi לערי ריינהארט 2005-08-03 19:46:54 UTC
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]]
Comment 9 Zbigniew Braniecki 2005-08-04 06:39:09 UTC
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)
Comment 10 Zbigniew Braniecki 2005-08-04 13:27:38 UTC
Created attachment 760 [details]
patch ver 4

Patch for trunk with fixed whitespaces and var names.
Comment 11 Brion Vibber 2005-10-22 21:40:14 UTC
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.
Comment 12 Zbigniew Braniecki 2005-10-23 11:59:04 UTC
no problem, I wasn't sure how it should be solved. Can we check in this patch
(without user_newtalk) then?
Comment 13 Zbigniew Braniecki 2006-05-04 21:34:17 UTC
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?
Comment 14 Brion Vibber 2006-05-05 01:40:54 UTC
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.
Comment 15 Zbigniew Braniecki 2006-05-05 11:06:27 UTC
investigating
Comment 16 Zbigniew Braniecki 2006-05-05 18:40:40 UTC
Brion: can you give me steps to reproduce it? It works for me.
Comment 17 Brion Vibber 2006-05-05 20:40:58 UTC
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
Comment 18 Zbigniew Braniecki 2006-05-06 01:07:51 UTC
Created attachment 1668 [details]
patch against 1.6.5 v2

ouch! Thanks, I screwed last patch. It missed } else { statement. Fixed in this
patch
Comment 19 Zbigniew Braniecki 2006-05-06 01:10:04 UTC
Created attachment 1669 [details]
patch against 1.6.5 v3

grr, removed debug value from DefaultSettings.php
Comment 20 Brion Vibber 2006-05-06 19:05:51 UTC
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?
Comment 21 Gregory Szorc 2006-07-16 07:00:43 UTC
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.
Comment 22 Gregory Szorc 2006-07-16 20:42:26 UTC
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.
Comment 23 Zbigniew Braniecki 2006-07-17 06:48:59 UTC
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.
Comment 24 Brion Vibber 2006-07-17 07:00:56 UTC
It needs to 1) work and 2) not break for our existing users
who use this feature, such as Wikia.
Comment 25 Gregory Szorc 2006-07-17 16:01:40 UTC
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).
Comment 26 Zbigniew Braniecki 2006-07-17 17:10:57 UTC
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.
Comment 27 Gregory Szorc 2006-07-18 02:53:21 UTC
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.
Comment 28 Gregory Szorc 2006-07-20 05:17:26 UTC
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 ;)
Comment 29 Brion Vibber 2006-07-20 05:21:16 UTC
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?
Comment 30 Gregory Szorc 2006-07-20 05:36:50 UTC
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.
Comment 31 Zbigniew Braniecki 2006-07-20 07:33:51 UTC
Can you elaborate more on "false positives"? Where would they appear?
Comment 32 Brion Vibber 2006-07-20 07:38:33 UTC
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).
Comment 33 Zbigniew Braniecki 2006-07-20 18:46:35 UTC
I agree with Brion here.

btw. Brion, who do you call second-largest MediaWiki user? :> On which position
MDC is? ;)
Comment 34 Gregory Szorc 2006-07-20 18:57:52 UTC
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?
Comment 35 Zbigniew Braniecki 2006-07-20 22:08:44 UTC
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...
Comment 36 Gregory Szorc 2006-07-20 22:49:48 UTC
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?
Comment 37 Brion Vibber 2006-07-20 23:09:19 UTC
(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?
Comment 38 Zbigniew Braniecki 2006-07-20 23:12:39 UTC
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?
Comment 39 Gregory Szorc 2006-07-20 23:22:46 UTC
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.
Comment 40 Brion Vibber 2006-07-21 06:16:55 UTC
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?
Comment 41 Zbigniew Braniecki 2006-07-21 06:21:14 UTC
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
:)
Comment 42 Gregory Szorc 2006-07-21 06:43:46 UTC
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?
Comment 43 Zbigniew Braniecki 2006-07-22 04:16:23 UTC
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...
Comment 44 Gregory Szorc 2006-07-22 17:13:46 UTC
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.
Comment 45 Gregory Szorc 2006-07-22 17:51:12 UTC
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.
Comment 46 Serguei Trouchelle 2006-09-06 15:17:03 UTC
Can you also look to Bug 7247 ? It seems to be concerned with shared user table
realizations. 
Comment 47 Zbigniew Braniecki 2006-09-07 00:43:09 UTC
Brion: please, comment this bug. We're ready with two competing approaches here,
and I'm not sure which one do you prefer?
Comment 48 Brion Vibber 2006-09-07 11:35:22 UTC
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.
Comment 49 Gregory Szorc 2006-09-07 13:20:57 UTC
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.
Comment 50 Zbigniew Braniecki 2006-09-07 17:15:55 UTC
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?
Comment 51 ThomasV 2007-01-15 06:56:55 UTC
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.
Comment 52 Lewis Jones 2007-01-25 16:58:14 UTC
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.
Comment 53 Lewis Jones 2007-01-25 16:58:43 UTC
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.
Comment 54 Rob Church 2007-01-25 21:19:40 UTC
(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.
Comment 55 Lewis Jones 2007-01-26 06:38:54 UTC
Thanks for that.  Sorry to bother you guys.

I'll have a hunt around.
Comment 56 Brion Vibber 2007-04-25 17:59:35 UTC
*** Bug 9695 has been marked as a duplicate of this bug. ***
Comment 57 Zbigniew Braniecki 2007-05-10 00:27:28 UTC
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?
Comment 58 John Joseph Bachir 2007-09-12 07:58:37 UTC
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
Comment 59 Daniel Friesen 2008-05-06 05:34:59 UTC
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.
Comment 60 Brion Vibber 2008-05-06 23:13:39 UTC
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
Comment 61 Daniel Friesen 2008-05-07 01:56:01 UTC
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.
Comment 62 Daniel Friesen 2008-05-07 05:05:42 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links