a var_dump on the $feed_node->feed_nid object returns the key as the nid instead of an incrementing key. This doesnt seem like the best way to build this array, Here is a patch that returns the array by an incrementing key instead.

["feed_nids"]=>
  array(1) {
    [46]=>
    string(2) "46"

becomes

["feed_nids"]=>
  array(1) {
    [0]=>
    string(2) "46"
CommentFileSizeAuthor
key.patch801 bytescangeceiro

Comments

aron novak’s picture

aron novak
Primary language Hungarian
Location Hungary, Budapest
commented
Status: Needs review » Needs work

You're right, the code does not rely on the value of the key.
But can you re-roll the patch according to this:

$array[] = $item;

This is a much more compact form to create a normally indexed array instead of using a separate variable for this.

alex_b’s picture

alex_b commented

Hang on - what's the problem that we're trying to solve here? I think I don't quite understand why using the feed_nid as key is not ideal.

cangeceiro’s picture

cangeceiro commented

I will re-roll that patch, good thinking, and thanks for the advice.

my reasoning behind the patch was for templating, if one needs to access that array somewhere else, it would make life easier for developers to access the nid by using keys, I can't imagine many situations where someone would need to access that array, and already know what the nid is with out putting in some logic to get that. it also makes more sense from a performance perspect to have the array being dense, as opposed to being sparse. It's more efficient on memory. but then again, i dont know for sure if php utilizes memory allocation in arrays like some other programing languages that do access memory this way.

alex_b’s picture

alex_b commented

#3: I think the cases you describe can be easily addressed with array_values(). The performance issue doesn't really matter I think given the low number of entries in the feed_nids array (on really large sites with about 2000 feeds the average is still less than 2 entries, with a mediam of probably 5 or 6).

On the other hand, Drupal is full of instances where the key reflects the id value (i. e. arrays of taxonomies on nodes).

I'd rather leave the behavior as is unless we can come up with a real problem that we can address by using an incremental key.

aron novak’s picture

aron novak
Primary language Hungarian
Location Hungary, Budapest
commented
Status: Needs work » Closed (works as designed)

Agree with alex_b, i mark this as "by design", i bet there is no significant performance gain.