Contrib.social

Schema API: rename field to column

Open on Drupal.org →
Created on 7 November 2007, over 17 years ago
Updated 20 March 2025, 16 days ago

CCK node types have "fields." A field can store data in one or more database columns or even no columns in the case of a computed field. Views have "fields" indicating what data will be displayed in lists or tables. Fields can be values from columns or arbitrary data returned by a handler function. Schema API defines tables to have "fields," too, but a Schema API field is really a database table column. This is very confusing, and if we release D6 with this terminology in place we will be stuck with it forever.

The only reason Schema API uses the term "field" instead of "column" is that the functions db_add_column() and db_change_column() already existed (they are pgsql utility functions in update.php). Frando and I felt it would be easier to get the Schema API patch in if we did not try to rename them. Now, I realize that was a mistake.

I presented this argument at the Boston Drupal User's Group meetup last night to 9 Lullabots, Moshe, and other developers and got wide agreement, no dissents.

The attached patch renames fields to columns. It also renames the old db_{add,change}_column functions to db_old_{add,change}_column (while officially only for pgsql they also work for mysql in most cases and some code (e.g. Views) uses them that way so we shouldn't put "pgsql" in the name). It's long patch but is little more than a big search and replace. With this patch applied, Drupal installs new and upgrades from D5 cleanly and results in a no errors on the schema.module comparison report. (The one exception to that statement is in block.module, http://drupal.org/node/190128, which is an unrelated bug.)

I'd like to get comments on this change from merlinofchaos, karens, and yched since they are/will be major users of Schema API; do they agree that the current use of "field" is confusing?

📌 Task
Status

Postponed: needs info

Version

11.0 🔥

Component

database system

Created by

🇺🇸United States bjaspan

Live updates comments and jobs are added and updated live.
  • stale-issue-cleanup

    To track issues in the developing policy for closing stale issues, [Policy, no patch] closing older issues

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Comment 16 days ago →
    🇺🇸United States smustgrave

    Thank you for creating this issue to improve Drupal.

    We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.

    Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

    Thanks!

  • Comment 16 days ago →
    🇮🇹Italy mondrake 🇮🇹

    This issue is, if I understand correctly, about the fact that the term 'field' should have never reached the database API, where it's all rows and columns.

    I think this is still a valid point, even if it's more a bit of an academic problem at the moment then anything else: everything works just fine as-is today - most probably people just got used to this.

    Since when this issue was born, we have now a proper deprecation process in place. If someone wants to tackle this, replacing Schema::addField, ::changeField, etc. with Schema::addColumn, ::changeColumn is feasible in an orderly manner. Probably a bit more problematic replacing SelectInterface::fields() and friends if nothing else because of the sheer amount of change it will imply.

  • Comment 16 days ago →
    🇺🇸United States smustgrave

    Thanks for following up!

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024