Re: about client-side cursors

Am Fri, Feb 05, 2021 at 11:40:31AM +0100 schrieb Daniele Varrazzo:

> >         class connection:
> >              def execute(self, query, vars)
> >                  cur = self.cursor()
> >                  cur.execute(query, vars)
> >                  return cur.fetchall()
> >
> > makes even more sense ?
> >
> > Perhaps even reconsider naming it "execute".
>
> If it didn't return a cursor, it would make sense to reconsider
> calling it execute(). As it is now it returns the same that cursor
> returns, it's pretty much just a contraption of a chain of methods,
> hence the same name.
>
> If you return just the fetchall list you lose access to results
> metadata (description), nextset, and someone will come asking "can I
> have executefetchone() please" the next minute :)

Yeah, I know. Therefore I thought maybe "conn.run_query()" or
some such because execute() is already loaded with meaning.

If one wants access to what a cursor provides, as defined by
the DB-API, one should _use_ a cursor, as per DB-API :-)

Or, perhaps, it returns a generator over the fetchall()
results list ?

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B