- 🇳🇿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 6:47pm 11 April 2024 - 🇩🇰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.