Differences in returned value

Hello,

I have been wondering why the PostgreSQL backend was returning a Record where you have to access properties as item, not attributes.

I was surprised because until now, I had relied on the sqlite backend and hoped that switching backend would be transparent.

It didn’t seem to be the case.

Am I doing something odd?

Thanks,

  • Sylvain

As a side note, the PostgreSQL backend doesn’t seem to play nicely with UUID column type. It tries to convert them to bytes when calling the record item.

Heya! We have to do this because accessing by attribute name could clash with other parts of the Record interface.

Having looked at https://github.com/encode/databases/issues/101 I think we can make a few improvements here. I’m currently thinking something like this…

row['title'] # Dict-style accesses.
row.column.title  # Attribute-style accesses.
row.c.title  # Shortcut attribute-style accesses.
row.index[0]  # Int-indexed accesses.

Do we have an open issue for this? Do we need one? (Unsure since it’s a brief description here)

Hi Tom,

Perhaps this:

I ended up doing this for now:

Yeah, this was the motivation behind https://github.com/encode/databases/issues/88 but we closed it assuming the key access was the right approach.

Having consistency across all backends is more important to me than choice here. Currently, key access is the only consistent one.

1 Like

Yeah, I agree with this one as well.
The main diffs are:

  1. 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.
  2. The exceptions in 1 are fetchval method that returns the only value and few other methods (like execute, 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.

Could you please provide more details about your issue?
I’m heavily using UUIDs with Postgres, so maybe I can help you or understand better your problem.

UPDATE: it’s probably already irrelevant.

Hi there,

I’ll refer you to the original issue that discusses my initial questions (unfortunately, it mixes both the way to access data with the issue of UUID causing trouble).

I think it’s better if we keep this discussion over to GH. I never come here and I find it hard to pay attention to this forum unfortunately :frowning:

Cheers,