Revolution: Coherence in table names

[frenchfries]

frenchfries created Redmine issue ID 10596

As those tables,
modx_system_settings
modx_user_settings modx_context_setting
should be
modx_akesse_context_settingS .

[OptimusCrime]

Nothing has happened here. I kind of agree, it would make a lot sense to have coherence.

I've learned that tables should never have plural names, so that means that a lot of tables should be renamed. What do you think?

[adamwintle]

This has probably never happened due to breaking changes. Maybe also why "modx_site_htmlsnippets" has never been renamed "modx_site_chunks"

However, if its possible I'd suggest making the changes too.

[garryn]

It might be possible, but not yet ... I think I remember having a conversation with @opengeek about this many a moon ago and I think there was a chance of being to include the ability to have table 'aliases' to allow for legacy and new table names to sit side by side (in regards the xPDO data model).

That, or we make the changes as part of 3.0 where there'll possibly be many breaking changes, table name changes might be apt for then.

[opengeek]

Changing table names is essentially a breaking change for backwards compatibility, as it prevents any existing code dependent on those names from working. For minor releases, we can add only features that do not break backwards compatibility. This kind of change will be more appropriate for a 3.x release.

[jpdevries]

I think it would be nice if we used microformats for things like user info and addresses. For example "familyname" instead of "lastname" and "givenname" instead of "firstname".

[mrhaw]

A small comment on that - firstname and lastname is what is being used in international english. Not that I care or criticize a change.

[OptimusCrime]

What is microformats?

[sottwell]

http://microformats.org/
https://github.com/indieweb/php-mf2

[OptimusCrime]

Isn't that concerning how the HTML output is formatted, and not the underlying column names?

Additionally, I thought this was mostly important for search engines? I see browsers support them too, but all of them require plugins or add-ons. Is there a real benefit for using microformats for "everyday" users? As far as I can tell, this is not an w3 standard?

[sottwell]

Well, yes and no. The issue is should this concept be supported at the lowest levels? If the database table and field names reflect some kind of standard, then it's far easier to automate the process of the controllers when generating the views. Of course, the question is, what standard? And what happens when the chosen standard changes or for some other reason isn't desirable?

This could be the purview of the controller layer - whatever fetches the data and organizes it for processing and output. Or it could be left up to the ultimate designer to translate the model to his view, which is less than helpful.

A MODX-classic example is the site_content's 'introtext' field. In the editing forms, it's labelled as 'Summary'. So somebody trying to use the [[*summary]] tag is going to have a problem. This is more a problem of presentation, but still, somebody should have done a bit more consideration the values of consistency. And yes, the actual field label is 'Summary (introtext)'. Three guesses who nagged and kvetched until that '(introtext)' bit got added...

[OptimusCrime]

Well, I guess that is a fair point, but there are endless examples of column names not matching the "friendly name" in various APIs and UIs.

The summary/introtext problem is really another issue, as the two names does not mean the same. Introtext is found between the title and the content, usually in a bigger font than the content. Summary is, well, a summary. The two does not correlate one-to-one.

However, my argument is that what the database field is called is irrelevant in the underlying implementation seen in context of users only using the [[*introtext]] or [[*summary]] placeholders.

[Ruslan-Aleev]

Related with https://github.com/modxcms/revolution/issues/14313

[sergant210]

Tables "membergroup_names", "member_groups" for user groups. And the next tables "user_group_role" and "user_group_settings" for user groups too.
Table "documentgroup_names" for resource groups. And table "access_resource_groups" for permissions.