Re: Another PDO ?
Matt Pelmear <[email protected]>
| Newsgroups | gmane.comp.php.database |
|---|---|
| Message-ID | <[email protected]> |
Jim, We have code that operates on tables that can be altered by users of the application (effectively storing different types of user data for each client). Some routines fetch results with PDO::FETCH_NUM as opposed to PDO::FETCH_ASSOC (or others), particularly when returning large amounts of data and performing manipulations on it in the code as well. columnCount can be useful here. (In fact, it comes from the mysql library directly, if I'm reading the code correctly.) -Matt On 09/10/2012 10:57 AM, Jim Giner wrote: > On 9/10/2012 10:53 AM, Graham H. wrote: >> I think it's so that you could write functions as generically as >> possible. >> So you don't have to pass in the number of columns or hard code in >> values >> for number of columns, you can dynamically check the column count for >> each >> result set that gets passed in. That's my guess. >> >> On Mon, Sep 10, 2012 at 8:51 AM, Jim Giner >> <[email protected]>wrote: >> >>> On 9/10/2012 10:49 AM, Bastien Koert wrote: >>> >>>> On Mon, Sep 10, 2012 at 9:48 AM, Jim Giner >>>> <[email protected]> >>>> wrote: >>>> >>>>> Reading up on the pdostatement class. Wondering what the intent >>>>> of the >>>>> columnCount function is. I mean, aren't the number of columns in a >>>>> result >>>>> known when you write the query? Granted, you might have some very >>>>> complex >>>>> query that you may not know the number, but for most queries you will >>>>> know >>>>> the columns you are expecting. So - what am I not seeing? >>>>> >>>>> -- >>>>> PHP Database Mailing List (http://www.php.net/) >>>>> To unsubscribe, visit: http://www.php.net/unsub.php >>>>> >>>>> >>>> It might be for those cases where you run a select * from ... >>>> >>>> But - again - one already knows how many fields are in that table >>>> when >>> one writes the query... >>> >>> >>> -- >>> PHP Database Mailing List (http://www.php.net/) >>> To unsubscribe, visit: http://www.php.net/unsub.php >>> >>> >> >> > I have not yet had a design where the results of queries could be > handled generically. Yes I may save some coding time in one way, but > for each field in a result the handling is not usually the same, > therefore my code would have to specify unique field names at some > point. This would only apply to a query that used * instead of > distinct names too. > > To me it seems a function with rather limited use. > -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php