Re: Extending "Limit" support
| From: | John Lim | Date: | Tue, 27 Nov 2001 16:50:20 +0000 |
| Subject: | Re: Extending "Limit" support | ||
| References: | 1 2 3 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-3130@lists.php.net to get a copy of this message | ||
Tomas V.V.Cox <cox@idecnet.com> wrote in message
news:3C01AF95.9CEAFFFF@idecnet.com...
> "Stig S. Bakken" wrote:
> >
> > "Tomas V.V.Cox" wrote:
> > >
> > > Hi,
> > >
> > > I've been playing with the limit support and want to make it avaible
in
> > > execute, getCol, getAssoc and getAll. But I'm not sure on the execute
> > > thing. For ex if I add it in execute it will look like:
> > >
> > > $db->execute($stmt, $data, $from, $count);
> > > but now query() doesn't have that params, it use limitQuery() instead
> > > and perhaps will confuse people. So to unify the API I propose:
> > >
> > > a) Add limitExecute() and use the limit* family to do that, or:
> > >
> > > b) Add the extra params from/count to query() and execute() and drop
> > > limitQuery(), loosing the chance of putting other coolest params in
the
> > > future.
> > >
> > > What way would you prefer?
> >
> > What about having a function that sets the limit for the next query?
>
> where "next query" means: query(), execute(), executeQuery(), getAll(),
> getCol() and getAssoc(). I dropped this idea because IMO it reduces the
> readability, but there are too much functions for being adding extra
> params to all of them, so perhaps this is not bad at all. So leave
> limitQuery() for this stuff, ex:
>
> $db->limitQuery($from, $count);
> $res = $db->query($sql);
Hi Tomas, Stig,
I like this idea too of using a 2nd function. This makes it cleaner
in the long run. particularly when you are passing bind arguments, this
is cleaner. Except that I would suggest something like:
$db->limitNextQuery($from, $count);
but maybe the name is too long. Nothing's perfect...
I would also love to see a standardized db api. Two possible
models to use would be the php_mysql api (for familiarity)
or php_odbc api (as ODBC has proven to be very portable).
Bye, John