Is it intentional that the first element is removed from the array in GetAssoc ??

[clarumedia]

ADOdb/adodb.inc.php

Line 4308 in e3e3d14

$key = array_shift($myFields);

What should happen when in fetch mode ADODB_FETCH_BOTH ? It seems to remove the first numeric index but leaves the first named index ?

If not, then maybe:

$key = reset($myFields);

This fix means that all of the fields are returned correctly when in fetch mode ADODB_FETCH_DEFAULT.
Otherwise, the first numeric index is missing.
I think this has been a bug for a very long time ?

However, I wonder if it might break functionality for developers who are NOT expecting to see the first field when in fetch mode ADODB_FETCH_ASSOC as a result of the way this has been coded ?

[mnewnham]

Could you provide a little code snippet and result that you are expecting to see vs what you actually see. Also, you seem to be asking 2 (or possibly 3) different questions in the same issue. You can help us by splitting the different questions into separate issues. Thanks

[clarumedia]

Tests using mysqli with this bug fixed: #886.

/* TEST TABLE */

CREATE TABLE xxxx (
  id int NOT NULL AUTO_INCREMENT ,
  flops enum('x','y') ,
  fucgher varchar(100) NOT NULL,
  word varchar(100) NOT NULL,
  log_id int DEFAULT NULL COMMENT 'SCSCSCSC',
  term_count int NOT NULL DEFAULT '123' ,
  test_dec decimal(65,2) NOT NULL,
  PRIMARY KEY (id)
);

INSERT INTO xxxx VALUES (14,'x','THDUEUGFERGDG','',NULL,123,'30.00');

PHP test code with different values for $ADODB_FETCH_MODE:

ADODB_FETCH_DEFAULT

Index (id) is in result set as a named item but not ordinal. Expected behaviour would be: first element: [0] => 14

$ADODB_FETCH_MODE=ADODB_FETCH_DEFAULT;
print_r($db->GetAssoc("select * from xxxx"));

Array
(
    [14] => Array
        (
            [id] => 14
            [0] => x
            [flops] => x
            [1] => THDUEUGFERGDG
            [fucgher] => THDUEUGFERGDG
            [2] => 
            [word] => 
            [3] => 
            [log_id] => 
            [4] => 123
            [term_count] => 123
            [5] => 30.00
            [test_dec] => 30.00
        )

)

ADODB_FETCH_ASSOC

Index (id) is NOT in result as named element at all. I "think" this is expected but is not very useful..to me....

$ADODB_FETCH_MODE=ADODB_FETCH_ASSOC;
print_r($db->GetAssoc("select * from xxxx"));`

Array
(
    [14] => Array
        (
            [flops] => x
            [fucgher] => THDUEUGFERGDG
            [word] => 
            [log_id] => 
            [term_count] => 123
            [test_dec] => 30.00
        )

)

ADODB_FETCH_BOTH

Index (id) is in result set as a named item but not ordinal. Expected behaviour would be: first element: [0] => 14

$ADODB_FETCH_MODE=ADODB_FETCH_BOTH;
print_r($db->GetAssoc("select * from xxxx"));

Array
(
    [14] => Array
        (
            [id] => 14
            [0] => x
            [flops] => x
            [1] => THDUEUGFERGDG
            [fucgher] => THDUEUGFERGDG
            [2] => 
            [word] => 
            [3] => 
            [log_id] => 
            [4] => 123
            [term_count] => 123
            [5] => 30.00
            [test_dec] => 30.00
        )

)

EDIT (dregad): added some formatting to make things easier to read

[clarumedia]

If I change line Line 4308 in e3e3d14 to use reset instead of array_shift, these are the results for the same thing:

ADODB_FETCH_DEFAULT

$ADODB_FETCH_MODE=ADODB_FETCH_DEFAULT;
print_r($db->GetAssoc("select * from xxxx"));

Array
(
    [14] => Array
        (
            [0] => 14
            [id] => 14
            [1] => x
            [flops] => x
            [2] => THDUEUGFERGDG
            [fucgher] => THDUEUGFERGDG
            [3] => 
            [word] => 
            [4] => 
            [log_id] => 
            [5] => 123
            [term_count] => 123
            [6] => 30.00
            [test_dec] => 30.00
        )

)

ADODB_FETCH_ASSOC

You could argue that in this situation, the existence of "id" as an element, "breaks" functionality. I'd say that it was more useful to have it there but I could see that it might break legacy code for somebody who was using the ordinal positions of the keys for something.

$ADODB_FETCH_MODE=ADODB_FETCH_ASSOC;
print_r($db->GetAssoc("select * from xxxx"));

Array
(
    [14] => Array
        (
            [id] => 14
            [flops] => x
            [fucgher] => THDUEUGFERGDG
            [word] => 
            [log_id] => 
            [term_count] => 123
            [test_dec] => 30.00
        )

)

ADODB_FETCH_BOTH

$ADODB_FETCH_MODE=ADODB_FETCH_BOTH;
print_r($db->GetAssoc("select * from xxxx"));

Array
(
    [14] => Array
        (
            [0] => 14
            [id] => 14
            [1] => x
            [flops] => x
            [2] => THDUEUGFERGDG
            [fucgher] => THDUEUGFERGDG
            [3] => 
            [word] => 
            [4] => 
            [log_id] => 
            [5] => 123
            [term_count] => 123
            [6] => 30.00
            [test_dec] => 30.00
        )

)

EDIT (dregad): added some formatting to make things easier to read

[dregad]

Thanks for the detailed info. I don't have time to fully analyze this right now, but to answer the original question:

Is it intentional that the first element is removed from the array in GetAssoc ??

The design choice of removing the first column is debatable, but per documentation the answer is YES. :
When more than 2 columns are requested, the first column becomes the key, all other columns become a numeric array beneath that key.

What is not normal though, is to get "half" of the first column in the array with ADODB_FETCH_BOTH.

Note to self: check what was getAssoc()'s behavior before #189/#198 were merged.

[clarumedia]

I ran a couple of further tests for 2 column queries which also produce unexpected results for ADODB_FETCH_DEFAULT and ADODB_FETCH_BOTH with array_shift on Line 4308 as per e3e3d14.

Expected Result for all would be:

Array
(
[14] => x
)

ADODB_FETCH_DEFAULT

$ADODB_FETCH_MODE=ADODB_FETCH_DEFAULT;
$arrData=$db->GetAssoc("select id,flops  from xxxx");

print_r($arrData);

Array
(
    [14] => 14
)

ADODB_FETCH_ASSOC

$ADODB_FETCH_MODE=ADODB_FETCH_ASSOC;
$arrData=$db->GetAssoc("select id,flops  from xxxx");

print_r($arrData);

Array
(
    [14] => x
)

ADODB_FETCH_BOTH

$ADODB_FETCH_MODE=ADODB_FETCH_BOTH;
$arrData=$db->GetAssoc("select id,flops  from xxxx");

print_r($arrData);

Array
(
    [14] => 14
)

Please note that using reset instead of array_shift makes ADODB_FETCH_ASSOC produce
Array
(
[14] => 14
)

[mnewnham]

@dregad, as both the author of the commit, and the author of the documentation, I can assure you that the behavior of getassoc() hasn't changed regarding the key. This was part of the original documentation that John wrote. I agree that it feels a little odd, but placing it into an evolutionary design perspective ( start with the original key/value pair, then add support for additional fields) it makes sense

[clarumedia]

@mnewnham that's fair comment, however, it looks like the behaviour of GetAssoc in ADODB_FETCH_BOTH and ADODB_FETCH_DEFAULT modes has been broken for a very long time with mysqli as per #885 (comment)

EDIT (dregad): fix issue comment link)

[dregad]

it looks like the behaviour of GetAssoc in ADODB_FETCH_BOTH and ADODB_FETCH_DEFAULT modes has been broken for a very long time with mysqli

@clarumedia You submitted that issue as #886, which was just fixed as I merged PR #900.

I don't have time to check whether that impacts or fixes this issue.