Deprecate either db_fetch_object or db_fetch_array. [#158115]

The availabilty of both db_fetch_object and db_fetch_array and no guidelines for using which where leads to inconsistent code, hooks and functions that can only be used with one but not the other.

Hooks.
Look at the comment hooks. Sometimes it's called with the comment as an object the other time with an assoc array. The only reason that this happens is because one time db_fetch_object is called before the hook and the other time db_fetch_array.

Functions.
drupal_unpack($obj) expects an object. Why? The author probably decided as such. But it means if you're going to use that function you usually do a db_fetch_object before. But now if one tries to standardize a module (say comment.module) to assoc arrays it's just not possible.

Code.
Every module author has his/her preference. But it leads to different coding styles and just incoherent code.

Deprecating either one would lead to much more consistent code and function arguments.

Comments

Comment #1

Jax CreditAttribution: Jax commented 29 July 2007 at 09:44

Here http://drupal.org/node/124141 is an example of what can go wrong by using _array() and _object() inconsistently.

Comment #2

Jax CreditAttribution: Jax commented 2 August 2007 at 15:22

Another example by W. Mostrey. In node.module the $node variable is often cast to an object to turn the assoc array into an object.

function node_view($node, $teaser = FALSE, $page = FALSE, $links = TRUE) {
  $node = (object)$node;


function node_submit($node) {
  global $user;

  // Convert the node to an object, if necessary.
  $node = (object)$node;


function node_validate($node, $form = array()) {
  // Convert the node to an object, if necessary.
  $node = (object)$node;


function node_access($op, $node = NULL) {
  global $user;

  // Convert the node to an object if necessary:
  if ($op != 'create') {
    $node = (object)$node;
  }

It's confusing to see all those casts in the code. Those are also cpu cycles that are wasted for nothing. So even if none of the functions is thrown away it might be an idea to only use one of the functions throughout core.

Comment #3

webchick

she/they

English

Vancouver 🇨🇦

CreditAttribution: webchick commented 17 January 2009 at 07:31

Issue tags:

+DX (Developer Experience)

This would be quite an undertaking, and I'm not even sure if it's possible to get that level of consistency given all the various inter-twining subsystems in Drupal, but I agree it would certainly help new developers struggle a lot less than they currently do.

Comment #4

Damien Tournoud CreditAttribution: Damien Tournoud commented 17 January 2009 at 10:21

This is closely related to #154859: Document that cached entity objects are not necessarily cloned any more.

Comment #5

David Strauss

he/him

CreditAttribution: David Strauss commented 8 March 2009 at 04:25

Status:

Active

» Postponed

Talked to Crell. Both of these functions will be removed following the complete DB:TNG conversion.

Comment #6

Berdir

German

Switzerland

CreditAttribution: Berdir commented 26 June 2009 at 23:31

Status:

Postponed

» Closed (won't fix)

I'd say we can even won't fix this. DBTNG does default to fetchObject(), unless you specificy something else.

But there are always use cases to use a non-default behavior, so we shouldn't deprecate or even remove something.

Comment #7

David Strauss

he/him

CreditAttribution: David Strauss commented 29 June 2009 at 05:51

Agreed on the "won't fix." The current array vs. object options (which are not the functions named in this issue's title) are handed down from PDO. Removing them would be awkward and increase DB-layer code complexity. At most, we should implement a coding standard for array vs. object and push core toward it.