Is there a consistent DB table naming scheme re plurals?

Is there a consistent DB table naming scheme re plurals?

Matt Gibson གིས-
Number of replies: 6

I'm aware that this will sound petty, but I'm getting really irritated that I keep having to go backwards and forwards to the DB viewer to find out whether a table has an 's' on the end or not:

With 's':

  • role_assignments
  • registration_hubs
  • course_categories
  • files
  • groups

Without 's'

  • question
  • user
  • course
  • lesson_branch
  • quiz_feedback

Or even two 's's:

  • groups_members

Apart from many-many tables seeming to reliably have 's' on the end, I can't see any consistency.

It would make SQL a lot simpler to write (especially for forgetful people like me) if we had a consistent policy. Any thoughts/preferences?

དཔྱ་སྙོམས་ཀྱི་སྐུགས་ཚུ།: -
In reply to Matt Gibson

Re: Is there a consistent DB table naming scheme re plurals?

Tim Hunt གིས-
Core developers གི་པར Documentation writers གི་པར Particularly helpful Moodlers གི་པར Peer reviewers གི་པར Plugin developers གི་པར

There is a consistent policy:

  • One-word table names are singluar (course, user)
  • Multi-word table names have the last word pluralised, the rest singular. course_modules, role_assignments, quiz_grades.

Unfortunately there are three types of exception to that:

  • Very old tables, that date from before the above policy was standardised (modules)
  • Places where people screwed up. (quiz_feedback is not that old, and I should have known better Hopefully the new code-review policies will eliminate new additions to this category.)
  • Places where the policy was broken for a good reason (file is a reserved word, and pluralising is probably the simplest way to avoid that; groups tables have a long and complex history, and at one point it was necessary to come up with new table names, so the singular group was replaced by groups).
In reply to Tim Hunt

Re: Is there a consistent DB table naming scheme re plurals?

Matt Gibson གིས-

Ah, I see. I suppose it will all work itself out in the end.

I've added a bit to the docs here: http://docs.moodle.org/en/Development:Database

In reply to Tim Hunt

Re: Is there a consistent DB table naming scheme re plurals?

james mergenthaler གིས-

Reminds me what my father used to say, "son, there is no black and white, only shades of gray".  It's important to have guidelines and policies, to avoid choas, but - there are always exceptions to the rules, especially in a big open source product like moodle.

peace.

In reply to james mergenthaler

Re: Is there a consistent DB table naming scheme re plurals?

Tim Hunt གིས-
Core developers གི་པར Documentation writers གི་པར Particularly helpful Moodlers གི་པར Peer reviewers གི་པར Plugin developers གི་པར

It should also remind you of the classic line in relation to internet standard "be strict in what you emit, liberal in what you accept". That is, any code you write yourself should follow all the coding guidelines perfectly. However, when looking at old code, you should be tolerant of what you find.

In reply to Tim Hunt

Re: Is there a consistent DB table naming scheme re plurals?

Ray Morris གིས-

I see that MOST modules don't follow that policy.  Is there any way to more actively encourage a policy to be followed?  Maybe because the rule itself is not consistent (some tables are supposed singular, others plural), developers don't notice that it's supposed to be consistently inconsistent?

Of the multi-word tables, exactly HALF and with an "s".  There are 259 multi-word tables. 130 end with an s.  So currently, a multiword table is equally likely to be singular as to be plural.  Most single word tables are singular, so it would be more accurate to say "all tables are singular" than to say "multiword names are plural".

 

 

In reply to Ray Morris

Re: Is there a consistent DB table naming scheme re plurals?

Tim Hunt གིས-
Core developers གི་པར Documentation writers གི་པར Particularly helpful Moodlers གི་པར Peer reviewers གི་པར Plugin developers གི་པར

You should sort your results by the date the table was added to Moodle. Most of the anomalies will probably be earlier in the development history (although there have been mistakes recently).

Once we have a table name that breaks the coding guidelines, there are two options:

  1. Fix it be renaming the table, which risks causing all sorts of regressions.
  2. Just live with it.

Often, option 2. is chosen, and it is hard to argue with that.

That is no excuse for you not getting it right in new code. In fact, it is a strong argument for getting it right first time.