Hi everyone!
My Google Summer of Code is finished, but the code I have written for the interwiki transclusion is not yet ready to be merged in trunk. Some optimizations have to be made and some little issues are still to be discussed.
The main remaining question is: should I use a separate DB or a shared table to store the GlobalTemplateLinks table? [1]
Following the advice of my mentor, Catrope, my code is currently using a separate DB (which name is stored in $wgGlobalDatabase) since it is the mechanism used by CentralAuth and it is very simple for users to set it up.
Platonides thinks that I should be using a shared table, since my code is not an extension. However, a disadvantage of shared table is that currently, adding a shared table in $wgSharedTables will force the user to share the users table, which is not always wanted.
I have further developments to accomplish on my code concerning database tables (such as creating a GlobalNamespaces table to store the distant namespaces names). I would like to solve this issue first, so that I don't have to rewrite everything later...
Can you please provide your opinion about this?
Thanks in advance
Best regards
[1] http://www.mediawiki.org/wiki/User:Peter17/Reasonably_efficient_interwiki_tr...
-- Peter Potrowl http://www.mediawiki.org/wiki/User:Peter17
Peter17 wrote:
Hi everyone!
My Google Summer of Code is finished, but the code I have written for the interwiki transclusion is not yet ready to be merged in trunk. Some optimizations have to be made and some little issues are still to be discussed.
The main remaining question is: should I use a separate DB or a shared table to store the GlobalTemplateLinks table? [1]
Following the advice of my mentor, Catrope, my code is currently using a separate DB (which name is stored in $wgGlobalDatabase) since it is the mechanism used by CentralAuth and it is very simple for users to set it up.
Platonides thinks that I should be using a shared table, since my code is not an extension. However, a disadvantage of shared table is that currently, adding a shared table in $wgSharedTables will force the user to share the users table, which is not always wanted.
I have further developments to accomplish on my code concerning database tables (such as creating a GlobalNamespaces table to store the distant namespaces names). I would like to solve this issue first, so that I don't have to rewrite everything later...
Can you please provide your opinion about this?
Thanks in advance
Best regards
[1] http://www.mediawiki.org/wiki/User:Peter17/Reasonably_efficient_interwiki_tr...
-- Peter Potrowl http://www.mediawiki.org/wiki/User:Peter17
$wgSharedTables is pre-populated specifically with user related stuff for backwards compatibility since originally enabling $wgSharedDB shared only the user table, it had no option to share anything else at all till I added it. The defaults for $wgSharedTables should only ever contain stuff to share users, but sharing users is not necessary. So if you've got something that uses a shared table (which would need configuration anyways) and people want to turn it on I'd say it would be reasonable to make setting $wgSharedDB and resetting $wgSharedTables to an empty array without the user related tables to be reasonable.
On Mon, Sep 6, 2010 at 3:55 PM, Peter17 peter017@gmail.com wrote:
Following the advice of my mentor, Catrope, my code is currently using a separate DB (which name is stored in $wgGlobalDatabase) since it is the mechanism used by CentralAuth and it is very simple for users to set it up.
Platonides thinks that I should be using a shared table, since my code is not an extension. However, a disadvantage of shared table is that currently, adding a shared table in $wgSharedTables will force the user to share the users table, which is not always wanted.
I think the difference between a shared database and a separate database are small, except that a separate database is more flexible. After all, you can always point your $wgGlobalDatabase to your local database (of false if you use wfGetDB!) to get your local database.
As a general comment, I think that it is not strictly necessary to have your global template usage in core. If you follow the example of the global image usage, the sharing feature (ForeignFileRepo) is in core, while the tracking feature (GlobalUsage) is an extension. Similarly, the interwiki transclusion can be in core, but the usage tracking can be an extension.
Of course we can also move global (image) usage to core and have "global" features there. Another option would be to create a unified global usage extension that supports file and template usage.
Bryan
2010/9/6 Bryan Tong Minh bryan.tongminh@gmail.com:
As a general comment, I think that it is not strictly necessary to have your global template usage in core. If you follow the example of the global image usage, the sharing feature (ForeignFileRepo) is in core, while the tracking feature (GlobalUsage) is an extension. Similarly, the interwiki transclusion can be in core, but the usage tracking can be an extension.
Of course we can also move global (image) usage to core and have "global" features there. Another option would be to create a unified global usage extension that supports file and template usage.
Typically, features are developed in extensions because that's easier, then considered for moving to core (the latter doesn't happen very ofiten, granted). GlobalTemplateUsage was written straight into core, and I see no compelling reason to keep it out of core, especially since it closely ties into one specific core feature.
Roan Kattouw (Catrope)
wikitech-l@lists.wikimedia.org