Drupal\Core\Database\StatementInterface::fetchAllAssoc() is unclear for the parameter $fetch. StatementPrefetch and Statement interpret the parameter differently.

Created on 1 March 2011, almost 14 years ago
Updated 11 April 2024, 8 months ago

DatabaseStatementPrefetch::fetchAllAssoc uses the $fetch_style directly, while DatabaseStatementBase::fetchAllAssoc checks if is a string. This causes the $result->fetchAllAssoc($this->idKey, 'MyClass') way of doing things to fail.

🐛 Bug report
Status

Active

Version

11.0 🔥

Component
Database 

Last updated 2 days ago

  • Maintained by
  • 🇳🇱Netherlands @daffie
Created by

🇩🇰Denmark xen

Live updates comments and jobs are added and updated live.
  • Needs backport to D7

    After being applied to the 8.x branch, it should be considered for backport to the 7.x branch. Note: This tag should generally remain even after the backport has been written, approved, and committed.

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.

  • 🇳🇿New Zealand quietone

    Is this still relevant to Drupal 10? There hasn't been any work here since the issue was created 12 years ago.

    Since we need more information to move forward with this issue, I am setting the status to 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!

  • Status changed to Active 8 months ago
  • 🇩🇰Denmark xen

    It's still relevant.

    Drupal\Core\Database\StatementWrapperIterator and Drupal\Core\Database\StatementPrefetchIterator (and the respective classes they're deprecating) both implements Drupal\Core\Database\StatementInterface.

    For the former, if the second argument to fetchAllAssoc is a string, it'll assume it's the name of a class and use FETCH_CLASS:
    https://git.drupalcode.org/project/drupal/-/blob/11.x/core/lib/Drupal/Co...

    The latter delegates fetchAllAssoc to fetch:
    https://git.drupalcode.org/project/drupal/-/blob/11.x/core/lib/Drupal/Co...

    Which will throw an exception if the fetch style is a string:
    https://git.drupalcode.org/project/drupal/-/blob/11.x/core/lib/Drupal/Co...

    StatementInterface describes the $fetch argument as:

       * @param $fetch
       *   The fetch mode to use. If set to \PDO::FETCH_ASSOC, \PDO::FETCH_NUM, or
       *   \PDO::FETCH_BOTH the returned value with be an array of arrays. For any
       *   other value it will be an array of objects. By default, the fetch mode
       *   set for the query will be used.
    

    Which doesn't exactly describe StatementWrapperIterator (it doesn't say that supplying a string is interpreted as a class, even if StatementWrapperIterator is returning an "array of objects"), but StatementPrefetchIterator is clearly not upholding the contract, as anything but an int corresponding to a fetch mode constant throws an exception.

    The interface needs to be more clear on the expected behaviour, and StatementWrapperIterator and StatementPrefetchIterator should interpret the arguments in the same way.

Production build 0.71.5 2024