Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Wikipedia: Wikitech

Standards for names of tables and $preferences for extensions

 

 

Wikipedia wikitech RSS feed   Index | Next | Previous | View Threaded


benapetr at gmail

Apr 18, 2012, 6:41 AM

Post #1 of 9 (487 views)
Permalink
Standards for names of tables and $preferences for extensions

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?

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


innocentkiller at gmail

Apr 18, 2012, 8:55 AM

Post #2 of 9 (408 views)
Permalink
Re: Standards for names of tables and $preferences for extensions [In reply to]

On Wed, Apr 18, 2012 at 9:41 AM, Petr Bena <benapetr [at] gmail> 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 [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


benapetr at gmail

Apr 19, 2012, 1:26 AM

Post #3 of 9 (453 views)
Permalink
Re: Standards for names of tables and $preferences for extensions [In reply to]

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 [at] gmail> wrote:
> On Wed, Apr 18, 2012 at 9:41 AM, Petr Bena <benapetr [at] gmail> 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 [at] lists
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


benapetr at gmail

Apr 19, 2012, 1:27 AM

Post #4 of 9 (449 views)
Permalink
Re: Standards for names of tables and $preferences for extensions [In reply to]

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 [at] gmail> 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 [at] gmail> wrote:
>> On Wed, Apr 18, 2012 at 9:41 AM, Petr Bena <benapetr [at] gmail> 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 [at] lists
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


emufarmers at gmail

Apr 19, 2012, 1:48 AM

Post #5 of 9 (405 views)
Permalink
Re: Standards for names of tables and $preferences for extensions [In reply to]

On Thu, Apr 19, 2012 at 4:27 AM, Petr Bena <benapetr [at] gmail> 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 [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


benapetr at gmail

Apr 19, 2012, 2:11 AM

Post #6 of 9 (405 views)
Permalink
Re: Standards for names of tables and $preferences for extensions [In reply to]

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 [at] gmail> wrote:
> On Thu, Apr 19, 2012 at 4:27 AM, Petr Bena <benapetr [at] gmail> 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 [at] lists
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


Platonides at gmail

Apr 19, 2012, 9:17 AM

Post #7 of 9 (445 views)
Permalink
Re: Standards for names of tables and $preferences for extensions [In reply to]

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.


_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


innocentkiller at gmail

Apr 19, 2012, 11:18 AM

Post #8 of 9 (403 views)
Permalink
Re: Standards for names of tables and $preferences for extensions [In reply to]

On Thu, Apr 19, 2012 at 12:17 PM, Platonides <Platonides [at] gmail> 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

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


Platonides at gmail

Apr 19, 2012, 1:26 PM

Post #9 of 9 (409 views)
Permalink
Re: Standards for names of tables and $preferences for extensions [In reply to]

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 mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Wikipedia wikitech RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.