I think we should create a page describing standards for names of keys in preferences and database objects for extensions. I propose to make it standard to prefix all keys in $preferences array with the name of extensions at least or some other words maybe (e_ExtensionName_Value ?).
The same should apply for database objects like tables. The main reason for this is to avoid collision given that we already have lot of extensions. What do you think?
On Wed, Apr 18, 2012 at 9:41 AM, Petr Bena benapetr@gmail.com wrote:
I think we should create a page describing standards for names of keys in preferences and database objects for extensions. I propose to make it standard to prefix all keys in $preferences array with the name of extensions at least or some other words maybe (e_ExtensionName_Value ?).
The same should apply for database objects like tables. The main reason for this is to avoid collision given that we already have lot of extensions. What do you think?
For database tables, I think as long as you're consistent within an extension, the prefix can be anything that makes sense.
For example, in CodeReview we use code_* for our table names.
-Chad
It's possible someone make extension which contains Code in name, so I think it would be best to use the full name of extension
On Wed, Apr 18, 2012 at 5:55 PM, Chad innocentkiller@gmail.com wrote:
On Wed, Apr 18, 2012 at 9:41 AM, Petr Bena benapetr@gmail.com wrote:
I think we should create a page describing standards for names of keys in preferences and database objects for extensions. I propose to make it standard to prefix all keys in $preferences array with the name of extensions at least or some other words maybe (e_ExtensionName_Value ?).
The same should apply for database objects like tables. The main reason for this is to avoid collision given that we already have lot of extensions. What do you think?
For database tables, I think as long as you're consistent within an extension, the prefix can be anything that makes sense.
For example, in CodeReview we use code_* for our table names.
-Chad
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I mean this would make development much faster. Now you have to look through hundreds of extensions to check if your new table isn't going to collide with some other.
On Thu, Apr 19, 2012 at 10:26 AM, Petr Bena benapetr@gmail.com wrote:
It's possible someone make extension which contains Code in name, so I think it would be best to use the full name of extension
On Wed, Apr 18, 2012 at 5:55 PM, Chad innocentkiller@gmail.com wrote:
On Wed, Apr 18, 2012 at 9:41 AM, Petr Bena benapetr@gmail.com wrote:
I think we should create a page describing standards for names of keys in preferences and database objects for extensions. I propose to make it standard to prefix all keys in $preferences array with the name of extensions at least or some other words maybe (e_ExtensionName_Value ?).
The same should apply for database objects like tables. The main reason for this is to avoid collision given that we already have lot of extensions. What do you think?
For database tables, I think as long as you're consistent within an extension, the prefix can be anything that makes sense.
For example, in CodeReview we use code_* for our table names.
-Chad
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Thu, Apr 19, 2012 at 4:27 AM, Petr Bena benapetr@gmail.com wrote:
I mean this would make development much faster. Now you have to look through hundreds of extensions to check if your new table isn't going to collide with some other.
There's a page on MediaWiki.org for registering extension namespaces.[0] If this is actually a problem, you could make something similar for table names.
[0] https://www.mediawiki.org/wiki/Extension_default_namespaces
That seems to be a lot of work which isn't needed. If we just prefixed the tables we wouldn't need to make a list of names which are already taken, because they would never conflict
On Thu, Apr 19, 2012 at 10:48 AM, Benjamin Lees emufarmers@gmail.com wrote:
On Thu, Apr 19, 2012 at 4:27 AM, Petr Bena benapetr@gmail.com wrote:
I mean this would make development much faster. Now you have to look through hundreds of extensions to check if your new table isn't going to collide with some other.
There's a page on MediaWiki.org for registering extension namespaces.[0] If this is actually a problem, you could make something similar for table names.
[0] https://www.mediawiki.org/wiki/Extension_default_namespaces
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 19/04/12 11:11, Petr Bena wrote:
That seems to be a lot of work which isn't needed. If we just prefixed the tables we wouldn't need to make a list of names which are already taken, because they would never conflict
Some db engines have limitations in the number of characters of table names. I think Oracle was the worst offender, with a 30 character limit. It's preferable to have a table named "lst_sections" than "LabeledSectionTransclusion_sec" (hitting the length limit). Plus, we should also keep some space for a possible $wgDBPrefix.
It may be interesting to store the tables used in $wgExtensionCredits, though.
On Thu, Apr 19, 2012 at 12:17 PM, Platonides Platonides@gmail.com wrote:
On 19/04/12 11:11, Petr Bena wrote:
That seems to be a lot of work which isn't needed. If we just prefixed the tables we wouldn't need to make a list of names which are already taken, because they would never conflict
Some db engines have limitations in the number of characters of table names. I think Oracle was the worst offender, with a 30 character limit. It's preferable to have a table named "lst_sections" than "LabeledSectionTransclusion_sec" (hitting the length limit). Plus, we should also keep some space for a possible $wgDBPrefix.
It may be interesting to store the tables used in $wgExtensionCredits, though.
Please, let's not pollute $wgExtensionCredits with this. When we overhaul extension installation/management, extensions should register these sorts of things there.
For now...is this an active problem, or are we just looking for one?
-Chad
On 19/04/12 20:18, Chad wrote:
Please, let's not pollute $wgExtensionCredits with this. When we overhaul extension installation/management, extensions should register these sorts of things there.
For now...is this an active problem, or are we just looking for one?
-Chad
Looks like the later. It can wait for extension management.
wikitech-l@lists.wikimedia.org