IRC

Re IRC: a silent failure is when something bad happens but the problem is ignored. It's not the case here, the ValueError is only masked if it can be remedied, if not we re-raise it.

I'm partway through a commit to update the documentation.

And I still haven't satisfied myself on the ways that our parse override could fail.

I'm dusting off my postgres.py dev env. I've got env's rebuilt for Python 2 and 3. Hitting an import error though ...

Imports clean up in #45.

I've got docs again locally.

I'm unraveling what the parse method is about to understand exactly what we're doing with it. I want to understand it and in particular how our implementation of it can fail, so that I can document it properly.

In the CompositeCaster constructor, parse is used as the adapter function, aka, typecaster, for new_type. It's this typecaster that is then passed to register_type underneath register_composite.

register_type ends up adding the type adapter to a dictionary that is ... somehow referenced when hydrating result sets.

I'm trying to find where the adapter function parse is called.

Looks like curs_get_cast dereferences the string_types dict (I'm not sure where binary_types gets looked at) and returns back to psyco_curs_cast, which is where the caster is actually called.

psyco_curs_cast ends up at Cursor.cast, but I'm not seeing where that's actually called outside of CompositeCaster.parse! Unless what we're getting is the result of curs_get_cast in pqpath? Looks likely, that's where DB-API 2.0's fetch seems to be implemented. Actually, fetch* is implemented in cursor_type.c, and pq_fetch is called under there. Okay!

So here's the call chain:

• one/all (us)
• fetch* (psycopg2)
• pq_fetch
• curs_get_cast
• parse

Yeah, binary casts appear to be broken:

FIXME: what the hell am I trying to do here? This just can't work..

:-)

psycopg/psycopg2#297 💃

Hmmm ... a little more complicated. Long story short, parse is called inside typecast_cast.

Alright. I'm back into parse, understanding how it works.

We have a list of tokens and a list of types. We also have a list of field names.

Here are the basic ways in which a type can change underneath us:

• a field can be removed
• a field can be added
• a field can change type

An arbitrary number of fields can be simultaneously changed in one of these three ways.

Changes to the type definition affect both reads and writes.

@Changaco Can you remind me why we need to support this? Why don't we just always restart the web app when the schema changes? Convenience?

What if we have an object with an update method and we pass data to it that gets stored in the wrong field because of a schema change between when the object was created and when we updated it? Is that possible?

More tomorrow ...

I mean, now that I revisit this, it strikes me as really weird to try to expect that the Python layer can seamlessly deal with an underlying schema change.

It's not weird to expect postgres.py to keep working when the schema changes, because it's not even supposed to know what the schema is.

I've added a commit to simplify our parse method: it occurred to me that we don't need to duplicate the code of psycopg's parse method like it was suggested in #26 (comment).

It's not weird to expect postgres.py to keep working when the schema changes, because it's not even supposed to know what the schema is.

Postgres.py itself isn't supposed to know what the schema is, but:

• Model is intended to be subclassed, and the subclass probably knows what the schema is, especially if it implements update methods.
• Instances of Model subclasses will have their attributes consumed by other code, which will expect a certain schema.

Any schema update is expected to result in other code changes, in the Model subclass as well as in consumers of subclass instances. If there is no code change, then what was the point of making the schema change? If there is a code change, then of course we need to restart the app.

I hate to say it, but I think we should close this PR. :-(

... though a documentation update could be in order. I can open a new PR for that.

Firstly, this PR is useful. It will reduce the downtime of the apps that use postgres.py, because it will no longer be necessary to take them down every time a backwards-compatible change to the DB schema is made, like dropping an unused column, or adding a new column with a default.

Secondly, what this PR (partially) fixes is a bug, I don't think it needs any other justification: bugs should be fixed whenever possible.

Secondly, what this PR (partially) fixes is a bug

Is #26 a bug? The fact that we can only partially fix it seems to be due to the fundamental constraints of a networked database, suggesting that, while it's certainly a constraint, it's not a bug. Can you explain why you see #26 strictly as a bug?

Very early on (I just spent some time looking for a relevant commit, but didn't find one) I worked around something like #26 on Gittip (at the time) with a three-step deploy process:

• deploy code that supports both the old and new schemas
• deploy the new schema
• deploy code that drops support for the old schema

I believe, given Python and Postgres, that's the only possible way to avoid downtime when we want to make a non-backwards-compatible schema change to the database.

It will reduce the downtime of the apps that use postgres.py, because it will no longer be necessary to take them down every time a backwards-compatible change to the DB schema is made

I can see the value in that. I still need to satisfy myself that supporting this use case doesn't introduce too powerful a footgun.

For the record, I'm being more conservative with this PR than I would for one on Gratipay or Aspen, because postgres.py has already achieved the status of a thoroughly-documented software product in a way that Gratipay and Aspen haven't yet. I want to change postgres.py deliberately and carefully.

Is #26 a bug? The fact that we can only partially fix it seems to be due to the fundamental constraints of a networked database, suggesting that, while it's certainly a constraint, it's not a bug. Can you explain why you see #26 strictly as a bug?

#26 is a caching bug, psycopg caches type definitions but it doesn't refresh them when they've become stale. Does it seem normal to you for a caching system to fail instead of refetching the data from upstream?

The fact that we can't fully fix this is not a "fundamental constraint of a networked database", it's just that postgresql wasn't designed to be used the way postgres.py uses it. It might be possible to modify postgresql to make the problem disappear entirely, but even if it is I don't want to wait for it.

I believe, given Python and Postgres, that's the only possible way to avoid downtime when we want to make a non-backwards-compatible schema change to the database.

You can't avoid downtime without this PR unless the changes only add or drop tables but don't modify any.

Alright, @Changaco, I'm merging this without further review, because a) I'm sure you'll want this for Liberapay, and b) I'm sure you'll quickly fix any bugs we're not seeing with it right now. :-)

Thanks, better late than never. :-)

FTR I hit a corner case that this PR couldn't fix while deploying Liberapay schema changes today. It was a type change of columns from bool to int.