I have a couple of questions before I do the next release of the TableEdit extension/special page 1) In the TableEdit extension, the table data is stored in an external mysql database. I had been hard-coding the name of this database into the extension to avoid creating a global variable that the user would put in LocalSettings. But it seems like that was a bad idea, especially if one wants two instances on the same mysql server... which I discovered I do want.
So, is there a recommendation for how to do this? Right now, the global is just $wikibox_db (the old name turned into a variable). Should it get a $wg prefix? I just want to make sure my extension plays well with others.
2) I'm not sure what I did, but I could have sworn that MW sent me back to the Special page if I log in from the special page. But now it's sending me back to the page that called the special page... which is not necessarily a bad thing in this case, but I don't get why it's doing that.
Thanks in advance, as usual for any input. ===================================== Jim Hu Associate Professor Dept. of Biochemistry and Biophysics 2128 TAMU Texas A&M Univ. College Station, TX 77843-2128 979-862-4054
On 28/07/07, Jim Hu jimhu@tamu.edu wrote:
I have a couple of questions before I do the next release of the TableEdit extension/special page
- In the TableEdit extension, the table data is stored in an
external mysql database. I had been hard-coding the name of this database into the extension to avoid creating a global variable that the user would put in LocalSettings. But it seems like that was a bad idea, especially if one wants two instances on the same mysql server... which I discovered I do want.
Is it essential to use an external database? Could you not use a number of tables in the same database as the wiki's using?
This strikes me as making life easier in terms of setup, and writing portable code, and also maintenance and backup operations.
Some trickery would be needed if you have to share data between wikis, but you could most likely achieve the desired effect by extending the shared table mechanism (which should be cleaned up, in any case) or using query groups to direct queries to the right database server and configuration, for more complex setups.
If you feel it *is* appropriate to use an external database, then I would certainly recommend making it configurable using a global (I despise globals, but we use them for configuration, so conventions are good). The "wg" prefix is a convention which was introduced to help indicate that a variable should be in the global scope; it helps us to spot missing "global $wgFoo" statements which cause notices, warnings and in some (well, a lot of) cases, downright stupid assumptions on the part of PHP.
When naming such configuration globals, be sensible; pick a name which isn't going to conflict with the core (for the foreseeable future). It's often a good idea to prefix the variable name with the extension name, e.g. $wgTableEditDatabase, etc.
Rob Church
Rob,
I wasn't sure if it's better to keep the extra tables in the wiki database or add them as tables to the MW table set. The latter would certainly work, and if that's preferred, it actually makes a bunch of the coding easier, and would undoubtedly make it easier to be compatible with installations that aren't using MySQL. As it is, I'm basically taking advantage of PHP's promiscuous mysql connections to talk to the external db using MW database object methods. I was thinking that I should keep my mitts off the base schema to make sure that I don't inadvertently conflict with some future MW schema change. But if you think I should add tables to the MW ones...
Although I share your dislike of globals, $wgTableEditDatabase will be the setting. For now I think I'll keep it outside unless a groundswell of the other MW devs and folks on the list second your thoughts. I think one could go either inside or outside during installation; if inside, then $wgTableEditDatabase could just be set to $wgDBname.
Jim
On Jul 28, 2007, at 4:49 PM, Rob Church wrote:
On 28/07/07, Jim Hu jimhu@tamu.edu wrote:
I have a couple of questions before I do the next release of the TableEdit extension/special page
- In the TableEdit extension, the table data is stored in an
external mysql database. I had been hard-coding the name of this database into the extension to avoid creating a global variable that the user would put in LocalSettings. But it seems like that was a bad idea, especially if one wants two instances on the same mysql server... which I discovered I do want.
Is it essential to use an external database? Could you not use a number of tables in the same database as the wiki's using?
This strikes me as making life easier in terms of setup, and writing portable code, and also maintenance and backup operations.
Some trickery would be needed if you have to share data between wikis, but you could most likely achieve the desired effect by extending the shared table mechanism (which should be cleaned up, in any case) or using query groups to direct queries to the right database server and configuration, for more complex setups.
If you feel it *is* appropriate to use an external database, then I would certainly recommend making it configurable using a global (I despise globals, but we use them for configuration, so conventions are good). The "wg" prefix is a convention which was introduced to help indicate that a variable should be in the global scope; it helps us to spot missing "global $wgFoo" statements which cause notices, warnings and in some (well, a lot of) cases, downright stupid assumptions on the part of PHP.
When naming such configuration globals, be sensible; pick a name which isn't going to conflict with the core (for the foreseeable future). It's often a good idea to prefix the variable name with the extension name, e.g. $wgTableEditDatabase, etc.
Rob Church
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/mediawiki-l
===================================== Jim Hu Associate Professor Dept. of Biochemistry and Biophysics 2128 TAMU Texas A&M Univ. College Station, TX 77843-2128 979-862-4054
Resending this because it doesn't appear to have reached the archive. (I've got to figure out how to make these use the right address) ~Daniel Friesen(Dantman) of The Gaiapedia, Wikia Graphical Entertainment Project, and Wiki-Tools.com
There is another convention you could use to avoid conflicting with MW functions. Some extension authors have considered w for wiki and e for extension. Also using f for function and g for global. So MediaWiki functions usually have wf and MediaWiki globals have wg. Sometimes when an author needs to make a global instead of using a $wg variable that will clash or a wf function that will clash. They use a $eg (Extension Global) and a ef function.
On another note. Has anyone ever thought of a MediaWiki message commons system? Like how we have an Image Commons system which an image takes the line: -Nonexistant -Commons -Local Meaning that if it's found locally it uses it, if not it falls back to common, if not it's nonexistant.
But what about a similar Message Commons, the current system goes: -Language Files -Messages Added to the MessageCache -Local Database But why not throw in a commons, something like: -Language Files -Messages Added to the MessageCache -Commons Database -Local Database
~Daniel Friesen(Dantman) of The Gaiapedia, Wikia Graphical Entertainment Project, and Wiki-Tools.com
Jim Hu wrote:
Rob,
I wasn't sure if it's better to keep the extra tables in the wiki database or add them as tables to the MW table set. The latter would certainly work, and if that's preferred, it actually makes a bunch of the coding easier, and would undoubtedly make it easier to be compatible with installations that aren't using MySQL. As it is, I'm basically taking advantage of PHP's promiscuous mysql connections to talk to the external db using MW database object methods. I was thinking that I should keep my mitts off the base schema to make sure that I don't inadvertently conflict with some future MW schema change. But if you think I should add tables to the MW ones...
Although I share your dislike of globals, $wgTableEditDatabase will be the setting. For now I think I'll keep it outside unless a groundswell of the other MW devs and folks on the list second your thoughts. I think one could go either inside or outside during installation; if inside, then $wgTableEditDatabase could just be set to $wgDBname.
Jim
On Jul 28, 2007, at 4:49 PM, Rob Church wrote:
On 28/07/07, Jim Hu jimhu@tamu.edu wrote:
I have a couple of questions before I do the next release of the TableEdit extension/special page
- In the TableEdit extension, the table data is stored in an
external mysql database. I had been hard-coding the name of this database into the extension to avoid creating a global variable that the user would put in LocalSettings. But it seems like that was a bad idea, especially if one wants two instances on the same mysql server... which I discovered I do want.
Is it essential to use an external database? Could you not use a number of tables in the same database as the wiki's using?
This strikes me as making life easier in terms of setup, and writing portable code, and also maintenance and backup operations.
Some trickery would be needed if you have to share data between wikis, but you could most likely achieve the desired effect by extending the shared table mechanism (which should be cleaned up, in any case) or using query groups to direct queries to the right database server and configuration, for more complex setups.
If you feel it *is* appropriate to use an external database, then I would certainly recommend making it configurable using a global (I despise globals, but we use them for configuration, so conventions are good). The "wg" prefix is a convention which was introduced to help indicate that a variable should be in the global scope; it helps us to spot missing "global $wgFoo" statements which cause notices, warnings and in some (well, a lot of) cases, downright stupid assumptions on the part of PHP.
When naming such configuration globals, be sensible; pick a name which isn't going to conflict with the core (for the foreseeable future). It's often a good idea to prefix the variable name with the extension name, e.g. $wgTableEditDatabase, etc.
Rob Church
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/mediawiki-l
===================================== Jim Hu Associate Professor Dept. of Biochemistry and Biophysics 2128 TAMU Texas A&M Univ. College Station, TX 77843-2128 979-862-4054
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/mediawiki-l
On 30/07/07, Dantman dan_the_man@telus.net wrote:
But what about a similar Message Commons, the current system goes: -Language Files -Messages Added to the MessageCache -Local Database But why not throw in a commons, something like: -Language Files -Messages Added to the MessageCache -Commons Database -Local Database
This is doable now; the MessageCache will call the "MessagesPreLoad" hook when searching for a message. I believe (although I've no idea if I'm correct in thinking this) that it's what Wikia use to facilitate their "SharedMessages" extension.
Rob Church
I'll be getting read/write access to Wikia's extensions on a development server soon as a volunteer tech so I can look into the code there to see how it's done there and compare with the location of the hooks to see if it's doable as a commons type system. Though I was thinking of something a little more integrated. Doing it as an extension makes it a little trickier to hook into the core methods of caching messages to reduce server strain, right?
~Daniel Friesen(Dantman) of The Gaiapedia, Wikia Graphical Entertainment Project, and Wiki-Tools.com
Rob Church wrote:
On 30/07/07, Dantman dan_the_man@telus.net wrote:
But what about a similar Message Commons, the current system goes: -Language Files -Messages Added to the MessageCache -Local Database But why not throw in a commons, something like: -Language Files -Messages Added to the MessageCache -Commons Database -Local Database
This is doable now; the MessageCache will call the "MessagesPreLoad" hook when searching for a message. I believe (although I've no idea if I'm correct in thinking this) that it's what Wikia use to facilitate their "SharedMessages" extension.
Rob Church
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Jim Hu wrote:
But it seems like that was a bad idea, especially if one wants two instances on the same mysql server... which I discovered I do want.
You have, I think, the info you need to create a table within the local Wiki database. $wgDBserver, $wgDBname, $wgDBuser and $wgDBpassword gets you into the database and
$wgDBprefix
will tell you which unique DB prefix is used for multiple wikis. Therefore, you can create a table with the name of $wgDBprefix.tableEditTableName and even if the user has two instances in the same MySQL, it will not conflict.
Mike
Hi Mike,
What I was worried about was not the prefixing, but rather that MW would someday change the schema to include a table called tableEditTableName, to use your example. The probability of this happening is admittedly low, but is higher for the possible names that are most obvious in describing the functions of the tables. If the TableEdit extension became really popular, then the devs would probably know not to clash with it, but I'm assuming that it's not widely used at this point and they might hit a namespace clash by accident with no malicious intent.
Of course, the MW devs are too smart to do what I did, and give a table a field name that is also a mysql reserved word!
Jim
On Jul 28, 2007, at 5:27 PM, Michael Daly wrote:
Jim Hu wrote:
But it seems like that was a bad idea, especially if one wants two instances on the same mysql server... which I discovered I do want.
You have, I think, the info you need to create a table within the local Wiki database. $wgDBserver, $wgDBname, $wgDBuser and $wgDBpassword gets you into the database and
$wgDBprefix
will tell you which unique DB prefix is used for multiple wikis. Therefore, you can create a table with the name of $wgDBprefix.tableEditTableName and even if the user has two instances in the same MySQL, it will not conflict.
Mike
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/mediawiki-l
===================================== Jim Hu Associate Professor Dept. of Biochemistry and Biophysics 2128 TAMU Texas A&M Univ. College Station, TX 77843-2128 979-862-4054
Jim Hu wrote:
What I was worried about was not the prefixing, but rather that MW would someday change the schema to include a table called tableEditTableName, to use your example. The probability of this happening is admittedly low, but is higher for the possible names that are most obvious in describing the functions of the tables.
I'd like to see a recommended standard from the Mediawiki developers that have an official convention for naming bits of extensions that are guaranteed not to clash with MW bits. For example, if all table names for extensions start with "e_", then you might have two extensions clashing but never have an extension clash with a MW table. Hence the full name will be the database prefix concatenated with "e_" concatenated with the table name.
I you want to get further carried away, perhaps a second bit that tries to encode the extension initials or something.
If we want to keep separate extension developers from clashing, it could be possible to add some info to a specific table on every extension page in mediawiki.org so that these things are identified. Something that groups the info by extension (something like Extension Matrix) could create a searchable page (via your browser's text search functions) to use as a kind of data dictionary.
Mike
mediawiki-l@lists.wikimedia.org