Deprecate either db_fetch_object or db_fetch_array.
| Project: | Drupal |
| Version: | 7.x-dev |
| Component: | other |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | won't fix |
| Issue tags: | DX (Developer Experience) |
Jump to:
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.
#1
Here http://drupal.org/node/124141 is an example of what can go wrong by using _array() and _object() inconsistently.
#2
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.
<?php
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.
#3
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.
#4
This is closely related to #154859: Document that objects are shared between modules.
#5
Talked to Crell. Both of these functions will be removed following the complete DB:TNG conversion.
#6
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.
#7
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.