Yeah, I agree with this one as well.
The main diffs are:
asyncpg provides the
Record objects already instead of simple tuples from other backends. And the
Record object is like the
namedtuple, but not exactly. So it allows access by key (as dict) and by index (as tuple) out of box, having keys named and in the order specified by the query.
- The exceptions in 1 are
fetchval method that returns the only value and few other methods (like
copy_to_db, etc.) that return the operation status like
INSERT 15 (inserted 15 rows).
Note: for p.1 there might be a mismatch and/or problems for “raw” sql queries as the
databases.Record relies on sqlalchemy details.
Personally, I generally quite like the native
Record object and for “raw” queries I usually unwrap it back as
record._raw and occasionally use statuses (like
INSERT 15) over “raw” driver interface as I can save on
returning for UUID ids, but still be aware the operation was successful.
So, I would rather think to decouple the Record object from the DB backend, so
- It can be generalised and defined once and used in all back-ends (mysql, sqllite, pg)
- it can be easily overridden/customised/defined by a user to meet specific needs
On the same note, I’d like to raise an idea that it would very handy to allow the user to define and use custom back-end. It has some benefits as well as drawbacks, but I wonder what you think about it.