[development] Extend database abstraction layer, to includetablecreation.

[Larry Garfield]

On Fri, May 12, 2006 2:44 pm, Angela Byron said:
> moshe weitzman wrote:
>
>> Pople might misuse it is not a justification for omitting code from
>> core. Building a collection from a db recordset an extremely common
>> pattern and including this convenience function reduces code and makes
>> it more readable. Do you think that improper instances of this will get
>> into core? No chance. It won't get into any of the well reviewed contrib
>> modules either. So what if people misuse a function in rarely used
>> contrib module? Thats likely the least of its worries.
>
> Agreed. But going back to my point, how do we know what field to set the
> array key on? Key on the first field selected? Or scrap the idea of
> hashes and just chuck them into a numeric array, knowing that in some
> (most?) cases you'll need to loop through it again to make the hash what
> you want? It would be nice for someone who is in support of a
> db_fetch_all() function to maybe grep through core/contrib looking for
> examples of this and come up with a sane default behaviour.
>
> -Angie

Also from my day job, where I wrote a Drupal-inspired db wrapper that
we're about to stop using anyway (long story), I had something along these
lines:

$options = db_get_keyed("SELECT field1, field2 FROM mytable ... ");

Poof.  One line to get a key/value set that's already perfectly prepared
to drop into a select box.  Yes, all these little utilities can be
misused, but that doesn't mean they can't also be very well used.  I'll be
writing Drupal equivalents (see the issue I posted earlier in this thread
for where I'm starting, and for some implementation suggestions) as I have
time to do so, because they really are useful.

--Larry Garfield