Re: Latest developments in psycopg3 - Mailing list psycopg

On Mon, 8 Feb 2021 at 15:16, Denis Laxalde <denis.laxalde@dalibo.com> wrote:
>
> Daniele Varrazzo a écrit :
> > On Mon, 8 Feb 2021 at 12:14, Denis Laxalde <denis.laxalde@dalibo.com> wrote:
> >> - It seems to me that the conn-info developments work fine (also looked
> >> at the commits, which look fine as well to me): what needs to be done
> >> here? Any help needed?
> >
> > I can't remember what is missing: probably the interface is complete,
> > it is missing test coverage and documentation. I will review if there
> > are methods missing: its purpose is to expose pretty much all the info
> > about the connection that the libpq can give, correctly decoded from
> > bytes. Complete tests and docs are definitely to be added.
>
> Ok, good to know. (Let me know if help is needed.)

That object should have more or less the same attributes of psycopg2
ConnectionInfo. [1] I looked again at the state of the branch and I
remember spending some time on get_parameters() (involving finding a
bug in the libpq). I haven't checked one by one the attributes but I
think a few are still missing. I would like to have at least one test
per attribute, just to catch regressions, and documentation, which
would largely be based on one line of docstrings and Sphinx
automethod.

So, not a difficult task, if a bit tedious. If you would like to help
on it I don't have work on that branch in mind in the next few days.


[1] https://www.psycopg.org/docs/extensions.html#psycopg2.extensions.ConnectionInfo


> > Which makes me think... 5) PydanticCursor? Or, as a more general case,
> > implement all the cursor flavours not as subclasses but using a
> > rowfactory function, and allow people to use their own (e.g. asking a
> > cursor to create a Pydantic model provided by the user, so that they
> > can have psycopg3 collaborate with e.g. FastAPI strictly typed
> > models). Or a Python dataclass...
>
> Providing a plugable API for that would be really nice, indeed.

For something more creative you could maybe take a look at this: maybe
we could give both the connection and the cursor a row_factory
attribute. I am not sure if just a callable would be enough: named
tuples, and in lesser measure dictionaries, would benefit from being
warned "a new result is coming: this is its shape". A clean interface
might be:

    class RowFactory:
        def set_result(self, cursor: BaseCursor):
            ...
        def make_row(self, values: Tuple[...]):
            ...

The library could provide some basic ones, for instance the equivalent
of DictCursor (real dicts) might be:

    class DictRowFactory:
        def set_result(self, cursor):
            self.titles = [d.name for d in cursor.description]
        def make_row(self, values):
            return dict(zip(self.titles, values))

This feature is definitely to be done before the first library release
but I can totally find something else to do and leave space to others.

Cheers

-- Daniele