On 08/02/21, Daniele Varrazzo (daniele.varrazzo@gmail.com) wrote:
> > - There appears to be no card about dictcursor on the project board.
> > What's the plan (and priority) for that (if any)?
...
> In psycopg2 there are:
>
> - DictCursor (returns a hybrid object between a sequence and a dictionary)
> - RealDictCursor (returns a straight subclass of a dictionary, so it's
> not a legit dbapi cursor as it doesn't expose a sequence)
> - NamedTupleCursor (what it says on the tin).
>
> Personally I use the NamedTupeCursor most often, as I prefer the dot
> notation to access attribute.
...
> 1) We can provide a feature to select the type of cursor that is not
> much dissimilar from psycopg2
> 2) Do we need DictCursor/RealDictCursor? ISTM that one of the two
> would be sufficient? Possibly an object inheriting from a Python dict
> instead of emulating it so that e.g. json.dumps()
> 3) Or, conversely, we could have a Row object providing both attribute
> and getattr access, both as index and name:
>
> row.myattr
> row["myattr"]
> row[1]
A comment on this point.
We use NamedTupleCursor a great deal as our system domain is modelled
largely in the database in plpgsql. The only issue we've had with using
NamedTupleCursor is when someone uses a space in column heading (the
space translates to a "_") or trips up and uses the same column name for
two columns. We class both cases as a mistake.
Instead of making the NamedTupleCursor the default, I imagine many
people accessing "raw" sql from python would benefit from the third
option, of permitting list, dict or getattr type access to values. This
would, presumably, be backwards compatible with current usage which I
imagine is typically list oriented.
A major benefit of getattr type access is that interactive debugging in
iPython allows dot expansion, so introspection of the the row's
attributes is wonderfully easy.
Regards
Rory