Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:33178
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <8D.46.01128.768AD374@pb1.pair.com>
To: internals@lists.php.net
Date: Fri, 16 Nov 2007 15:25:40 +0100
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.0
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: RFD: PDO::FETCH_2D or a hierarchical FETCH_ASSOC
From: hp@oeri.ch (Hans-Peter Oeri)

Hi!

I'm surely not the only one that ran into the problem of queries
returning several columns with identical names. I didn't find anything
about my following suggestion in the archives - if however, I'm only
warming up old cheese, please ignore/bash me ;)

As I see, there is an connection attribute ATTR_FETCH_TABLE_NAMES that -
depending on driver support - qualifies column names:

column 'a' on table 'b' => $result['b.a']

Given support for that attribute, a FETCH_ASSOC returns a
one-dimensional array with qualified column names. However, I don't
consider this solution as good as it could be... E.g. it's rather hard
to extract the values from a specific table (short of running over the
whole index array). There is useful information "hidden" in the text...

I therefore suggest a fetch mode that returns TWO-DIMENSIONAL arrays,
the first dimension being the table/relation name, the second the column
identification:

column 'a' on table 'b' => $result['b']['a']

Such a solution would ease a lot of my 'framework' tasks.

Open questions/ideas:
- columns not originating from a table?
  Those could be entered in the first hierarchy (possibility
  of conflict with table names):
  $result['computed_value']
  or in sort of a 'pseudo table' like '0' or 'unknown' (possibility of
  conflict by that pseudo name):
  $result['unknown']['computed_value']

- separate fetch mode or mode modification flag?
  There could be uses for a modified FETCH_BOTH as well, with
  column numbers all on first level plus hierarchical FETCH_2D.

- what about a hybrid fetch?
  There could be uses for sort of a hybrid fetch, which would result
  in FETCH_ASSOC (each column name only once, first level) plus
  FETCH_2D (all columns hierarchically). To reduce memory consumption,
  the "doubly represented" columns could share a Z_VAL reference.

Compatibility issues:
- A quick glance only reveals fetchColumn and getColumnMeta as obvious
  compatibility issues. Should they be enhanced to not only accept
  column numbers, but textual column identifiers as well...

- A hybrid mode (see above) that works 1:1 with existing code
  plus offers the advantages of hierarchical access would only be
  feasible with 'hidden' keys. I don't think that's necessary.

What do you think?

HPO