Re: pdo comments
| From: | Dan Scott | Date: | Mon, 18 Oct 2004 23:00:53 +0000 |
| Subject: | Re: pdo comments | ||
| References: | 1 2 3 4 5 | Groups: | php.pecl.dev |
| Request: | Send a blank email to pecl-dev+get-1481@lists.php.net to get a copy of this message | ||
On Tue, 19 Oct 2004 00:10:31 +0200, Lukas Smith <lsmith@php.net> wrote:
> Wez Furlong wrote:
> > On Mon, 18 Oct 2004 23:53:59 +0200, Lukas Smith <lsmith@php.net> wrote:
> >
> >>The thing is though that in oracle the are converted on insert and not
> >>when you fetch the data. Therefore this could result in portability
> >>issues, that seem easy to solve.
> >
> >
> > The problem with doing it on insert is that we can't catch all cases
> > where empty strings go in, without implementing a full blown SQL
> > parser, and that is something we really really don't want in PDO. If
> > you can't do it in all cases, then you'll be creating inconsistent
> > insert behaviour, and that is something we don't want in PDO either.
>
> ok, point taken
>
> >>>>6) Does it make sense to have fetch() as part of the statement object
> >>>>instead of having result sets having their own class?
> >>
> >>>It's less painful to use having the the result set merged into the
> >>>statement handle, so IMO (and that of the perl guys) this is better
> >>>than having a separate result set class.
> >>
> >>Well it seems to be a little odd from a design perspective and I dont
> >>really see the advantage besides having one less class.
> >
> >
> > one less class means one less instance per query, and less messing
> > around to get at the data; PDO is about making it easier to get at the
> > data, not about having the best theoretical OO design.
> >
> >
> >>But beyond that
> >>it mixes two totally separate things. A statement doesnt necessarily
> >>contain a result set.
> >
> >
> > fetch() will raise an error in that case.
>
> But this closes the door for having buffered queries, which is what PHP
> users are accustomed to. Beating them towards unbuffered queries and
> leaving only the option of a fetchAll() isnt exactly simple imho either.
>
> I also dont see where this makes things easier.
Can you explain how PHP users are accustomed to buffered queries? Would
that look something like $row_array = $sth->fetchMany(10); ?
I'm coming from Unified ODBC, and I'm certainly not accustomed to them.
while ($row = $sth->fetch()) {
// do something with $row
}
seems like a perfectly reasonable control structure to me. But I admittedly
come from an ODBC / Perl DBI world, so you might consider me perfectly
unreasonable :)
Dan