Consistent table names to facilitate CRUD operations

I'm supportive for this. (Although, I don't think it is a showstopper for the data API to progress. I'd prefer to see us work on the data API first, and then worry about table name cleanup but I won't be picky.)

Refreshing the patch after the Schema API being applied.

See http://drupal.org/node/145684 for some ideas of what this patch would open up.

Oh, YES PLEASE!!! This has bugged me forever.

Adding to my "definitely test" queue. Thanks, Nedjo!!

Oh, I should point out too a +1 to singular table names. There was a huge thread about table naming conventions I read a long time ago, since I'm a total sucker for that kind of stuff. ;) The consensus was that singular better because:
a) it's more consistent (for example, should the bridge table between users and roles be user_roles or users_roles or..?)
b) it's easier for non-English people to grasp, as they don't have to remember weird pluralization rules in English (boxES vs. blockS).
c) it makes more sense in most queries; you want to select a name from a particular user, not a name from all of the users (generally speaking).

Ok re-rolled with a few fixes:

• There were still references to {users_roles} in user.module.
• The files table wasn't renamed to file in system.schema.
• There were still references to {menu_links} and {comments}.
• The node_comment_statistics table wasn't renamed to node_comment_statistic (not sure if we want that or not, but I figured I'd keep them consistent).
• term_data wasn't renamed to term.

I went around and clicked on most things and seemed to go ok. Definitely could use another set of eyes, though.

Also, an update path is missing. I need to read up in the documentation to figure out how to write that.

And for those following along at home, here are the name changes:

This will break approximately every snippet in the handbook. ;) However, it makes the data schema FAR more consistent and easy to grok for new developers, and provides a consistent means to handling the Data API, through clever introspection.

Thanks Angie! That was just the careful attention and fixing up the patch needed.

For the update, I'm not exactly sure what we need to do. Here's a suggested approach:

* Change names of all existing tables. Do this update in system module, so that it's run before other modules' updates. We have a relevant snippet from content.install:

* Use the new names for all post-5.x updates in all modules' install and update functions. For example, php_install() includes handling of existing filter formats. I included one update function in the table name changing, locale_update_6001().)

Does that sound right?

I also wondered above about how to handle the case that the new names are already taken by contrib modules' tables, and suggested we simply rename those existing tables. Does that sound right?

(I'm unassigning myself in the hope I can leave this in your capable hands, but do let me know if there's ore I can do :) )

no, I think the update paths are different now, post-schema patch. I'll try and find out. :)

We'll also need to update the sequences table so that {node_revisions}_vid, for example, becomes {node_revision}_vid.

The whole 'renaming takes a name already taken by contrib' is... interesting. I hadn't thought of that. but yeah, probably something like check first if the table exists. If so, output an error and don't attempt the rename until it's resolved?

As long as we don't go the Rails direction with a giant pluralization dictionary (and this patch doesn't), this sounds like a good idea.

See this patch http://drupal.org/node/147285 to add db_rename_table(), which would be useful here.

i think this would be a good change. it was a bit frustrating initially trying to remember the table names. i just hope the files patch that renames file_revisions to upload sticks before this.

I'm thrilled to see this patch!

I actually rolled a patch to rename all the core tables about a month ago, but then when I started addressing the problem of doing the update from D5 to D6, I very quickly realized that was the hard part. :-)

Whatever renames the tables has to operate in such a way to not interfere with the many other updates that need to run, as well.

I'm rather of the mind that contrib modules which conflict with renamed core database tables need to be altered to avoid the collision.

Actually, I also rather like the idea of making the table naming convention a hard and fast rule for contrib, too. If you write a module and use a table name that's plural, your module doesn't get published. But I'm sure there will be little support for that, nor any easy way to automate it. At least it should be so documented in the coding standards. Consistency really reduces effort, errors and improves quality, which is why we have coding standards, right?

Nedjo++ !

Massive hunk failures.

Ah, crap. I totally meant to re-roll this but little point in it now.

Will make this my first priority for D7, aka, "The fantastically CRUDdy release." ;)

postponed now is less needed, maybe when a patch needs to postponed within the same cycle. adjusted status.

Bumping this, if only because I can never remember which ones are plural and which aren't, and that's annoying.

Still bugs the heck out of me. :-)

If we fix pluralisation, we can add something in coder.module to check this too :)

Me too. But obviously, I'm not working on this anymore. :)

I saw #4 'b' and my gut reaction was 'Hurrah!'. One of the joys of Drupal is the diversity of the users and contributors. On reflection though, irregularity of English pluralisation is probably not one of the highest hurdles a non-native speaker suffers.

This issue crops up in many projects, not just Drupal. Imagining the inconsistency to be about singular vs plural is to oversimplify it.

A table such as 'users' contains rows where each row describes a user. A 'menu_router' table is (I guess) so named because its purpose is to be used in routing, not because each row is a menu router.

If you want consistency you have to understand English grammar well enough to understand the role collectives play (and Fowler's Modern English Usage has seven sections in his article on this!).

So you would rename 'users' not 'user', but some choice such as 'population' or 'flock'. I'm not for an instant suggesting you do this, you'd be throwing the baby out with the bathwater. I'm just trying to explain why the original choices are not quite as illogical as they might seem at first sight.

Those kind of patches tend to be giant, so I suggest splitting it up by modules, so:

system.module

actions
actions_aid
blocked_ips
files
menu_links
sessions

block.module

blocks
blocks_roles
boxes

comment.module

comments

filter.module

filter_formats
filters

node.module

node_revisions

poll.module

poll_choices
poll_votes

user.module

users
users_roles

taxonomy.module

vocabulary_node_types

I've posted a patch for renaming user module tables: #330983: Rename user module tables to singular.

I've forgot to enable all core modules before making the previous list. Those ones also need renaming:

blogapi.module

blogapi_files

locale.module

languages

profile.module

profile_fields
profile_values

search.module

search_node_links

trigger.module

trigger_assignments

I think splitting by module makes sense, since we only need one update function per module.

Ok, block.module's tables got renamed.

I've submitted a new patch for renaming node, filter and comment module tables.

The upgrade path for user and system tables will be more difficult to write, since those tables are used for access check in update.php. So I'll work on renaming those tables on the same patch.

More coming.

What is exactly the use of this? Some sort of research for a "conceptual beauty of table naming"?

I'm really -1 for all this. We shouldn't waste effort on such a trivial matter.

@Damien Tournoud: Who is wasting efforts? Is it you?