Problem/Motivation

Follow-up from #2425127: Prevent PostgreSQL from creating duplicated index names within schema. The method name ensureIdentifiersLength does not document what it does accurately and should be renamed accordingly.

  /** 
   * Make sure to limit identifiers according to PostgreSQL compiled in length.
   *
   * PostgreSQL allows in standard configuration no longer identifiers than 63
   * chars for table/relation names, indexes, primary keys, and constraints. So
   * we map all identifiers that are too long to drupal_base64hash_tag, where
   * tag is one of:
   *   - idx for indexes
   *   - key for constraints
   *   - pkey for primary keys
   *
   * @param $identifiers
   *   The arguments to build the identifier string
   * @return
   *   The index/constraint/pkey identifier
   */
  protected function ensureIdentifiersLength($identifier) {

Proposed resolution

Rename the method to "hashIdentifierLength" and update the use of that method throughout core.

Remaining tasks

User interface changes

None.

API changes

Yes. However this is an internal protected method for pgsql driver.

Beta phase evaluation

Reference: https://www.drupal.org/core/beta-changes
Issue category Task because this is a clean up issue to make the method name more readable.
Issue priority Normal because it improves the naming of methods/classes.
Prioritized changes A follow-up issue from a Major PostgreSQL #998898: Make sure that the identifiers are not more the 63 characters on PostgreSQL. @xjm also has signed off on the change as reducing fragility (see #9).
Disruption Disruptive for contributed modules subclassing postgres' schema class (extremely unlikely currently).

Comments

Nafes’s picture

Status: Active » Needs review
StatusFileSize
new6.96 KB

After a bit of discussion with @Cottser, and @mparker17 at the DrupalNorth2015 code sprint, here is a patch to change the function's name to hashIdentifierLength().

@mparker17 remembered that views-7.x-3.x hashes block machine names to ensure they don't exceed 32 characters, so we decided to look at the Views code to see whether it set a naming precedent. Turns out the code was done in views_block_info(), not a function.

We also checked to see if the hashing function was ported to Drupal 8, but we weren't able to find it.

Since we couldn't think of any more precedents, we brainstormed the best name for the function, and decided on hashIdentifierLength().

***

Would it also be worth updating the function docblock? It's okay, but the order of some words is a bit confusing.

Nafes’s picture

Issue tags: +#DrupalNorth

Tagged as DrupalNorth. Have been completed on Drupal North code sprint.

daffie’s picture

Status: Needs review » Reviewed & tested by the community

The new name seems to as a good solution.
All instances are renamed.
For me it is RTBC.

mradcliffe’s picture

Issue summary: View changes
Priority: Minor » Normal
Status: Reviewed & tested by the community » Needs review

I reviewed the issue summary and corrected issue priority to more closely match what it should be after evaluating the issue via the Beta Evaluation process.

My one question about the patch is has it run through at least the Database test suite on PostgreSQL? I don't see any mention of running @Nafes' patch on drupalci test bot. I need to rebuild my local drupalci environment on this machine still, and will try to run that today.

Nice work on the patch, @Nafes. I really wanted to make it up to Canada too. :(

Nafes’s picture

Thanks! Maybe next year in Montreal :)

Anonymous’s picture

Issue tags: +DrupalNorth2015

Updating the issue tag to include a hashless DrupalNorth2015 on behalf of the Drupal North sprinting group.

mradcliffe’s picture

Status: Needs review » Reviewed & tested by the community
StatusFileSize
new9.86 KB

I ran a postgresql 9.1.2 drupalci testbot run for Database and Entity groups, and all tests pass in those groups.

mradcliffe’s picture

Issue tags: -#DrupalNorth

Oops, did not mean to revert that tag removal.

Edit: or maybe it wasn't removed. It was an edit conflict and then I went ahead and saved anyway. Doesn't hurt to just use the hashless tag.

xjm’s picture

Issue summary: View changes
Status: Reviewed & tested by the community » Needs review

Thanks for the beta evaluation. I thought a bit about whether this change indeed makes sense during the beta despite being an API change. As the summary points out, this is a followup for a major earlier during the beta, and I agree that the current method name is indeed actively misleading, so it reduces fragility in that sense as well. The only disruption as far as I could tell would be for someone subclassing the PostgreQL driver, which seems extremely unlikely right now since D8 only recently works well on Postgres. :)

However, I'm not sure about the method name. It's not hashing the identifier length -- that would be, like, a hash of an integer.

How about something like getIdentifierHash()?

Nafes’s picture

Looks very good. After freezing method name I can re-create the patch.

mparker17’s picture

+1 to getIdentifierHash()! :)

Nafes’s picture

StatusFileSize
new6.92 KB

This is an updated patch for getIdentifierHash().

bzrudi71’s picture

Status: Needs review » Needs work

The last submitted patch, 12: change_method_name_for-2426579-12.patch, failed testing.

daffie’s picture

Issue tags: +Needs reroll
bzrudi71’s picture

getIdentifierHash() feels wrong. In 99% of all cases the identifier isn't hashed at all, just if it exceeds the 63 chars limit. So better something like hashOverlongIdentifiers()?

nikky171091’s picture

This is an updated patch!

bzrudi71’s picture

Status: Needs work » Needs review

Thanks @nikkR! We should test this :)

Status: Needs review » Needs work

The last submitted patch, 18: Change-method-name-for-pgsql-driver-2426579-18.patch, failed testing.

rajeevk’s picture

StatusFileSize
new7.08 KB
new1.55 KB

Line indent corrected..

rajeevk’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 21: 2426579-21.patch, failed testing.

The last submitted patch, 21: 2426579-21.patch, failed testing.

bzrudi71’s picture

Status: Needs work » Needs review
StatusFileSize
new7.35 KB

Well, #18 seems to fail for some reason and there is no interdiff, so let's start from scratch...

bzrudi71’s picture

Sadly the PG fail in #25 is unrelated and reminds me of #2565241: First test fails on postgres because of a stale connection (will report over there). And while waiting for the second bot run, what about hashOverlongIdentifierNames() :)

googletorp’s picture

Issue tags: -Needs reroll

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

daffie’s picture

Version: 8.1.x-dev » 8.2.x-dev
Status: Needs review » Reviewed & tested by the community

For me +1 for getIdentifierHash().

My review:
- I have checked that all uses of ensureIdentifiersLength() have been replaced.
- The testbot for PostgreSQL gives 3 fails and the daily testrun for PostgreSQL gives the same 3 fails. So they are not the result of this patch.
- I all looks good to me.

catch’s picture

Status: Reviewed & tested by the community » Needs review

I'm not sure this is misleading, or that the new method name is better:

- this method ensures that the length of an identifier is within the limits set by postgres - at least that's the original reason for the naming. What exactly is misleading about it?

- it only hashes if the length is going to be too long, otherwise it keeps the original name, so getIdentifierHash() doesn't describe what it does.

What about something like normalizeIdentifierLength()?

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

andypost’s picture

Status: Needs review » Needs work
Issue tags: +Needs reroll

++, Needs reroll to change to normalizeIdentifierLength

pk188’s picture

Status: Needs work » Needs review
StatusFileSize
new7.36 KB

Re rolled.

jofitz’s picture

Issue tags: -Needs reroll

Please remember to remove the "Needs reroll" tag.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

smustgrave’s picture

Issue summary: View changes
Status: Needs review » Postponed
Issue tags: +Needs Review Queue Initiative

Postponing until #1060476: Multiple issues when PostgreSQL is used with non-public schema is merged in

Then we will need a reroll to address the renaming being requested by @catch in #30 and @andypost in #33

Updating issue summary

Please do not just reroll

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

xjm’s picture

Status: Postponed » Needs work

The issue mentioned in #47 has been committed.

#30 still needs to be addressed, though. Plus, the previous patch is renaming the method without following the deprecation policy (because the proposed change and my previous signoff predate the deprecation policy). We should add a proper deprecation instead of the BC break.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.