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