add column to packages for current_serial, as well as trigger on journal... #195
Conversation
…nals to keep it up to date. this will allow our XMLRPC call for list_packages_with_serial() to execute without the insane join
| FOR EACH ROW | ||
| EXECUTE PROCEDURE update_packages_current_serial(); | ||
| """) | ||
| op.execute(""" |
There was a problem hiding this comment.
I wouldn't apply this as a part of the migration. I'd recommend doing this as a backfill on all columns that are NULL later.
There was a problem hiding this comment.
ahhh, the NULL check should be part of this command regardless.
There was a problem hiding this comment.
Yeah, I'd just separate this data migration from the schema migration personally. Since this is going to just update 40k rows. Everything else is non-blocking.
There was a problem hiding this comment.
i'd approximate the update to block for only 20 to 30 seconds based on benchmarks for the select i performed last night.
There was a problem hiding this comment.
That's fine. We can do this with 0 blocking though. :) But the downtime is your call. I also, out of principal, like to keep data and schema migrations separately. The schema migration here is safe to apply at any time, and you'd want to more-or-less, schedule the data migration or run it offline, etc. Again, not sure how things are set upw tih pypi or how things are typically done. Just my 2 cents.
There was a problem hiding this comment.
the migration is going to run in a transaction, so there are two things i think i can confidently say:
NULLcheck is good practice, but shouldn't be necessary- calls to the
packagestable in the meantime will just wait for the transaction to finish, so downtime shouldn't be necessary.
There was a problem hiding this comment.
Well, if that's a risk you're willing to take, then I'd just do this all in one shot and remove the nullable constraint at the end. Or just set a default and let it block while writing the column.
I only suggested making it nullable assuming a data migration "at some point in the future".
|
Do we still need/want this with the tuning we've done to PostgreSQL? |
|
i don't think it'll be necessary quite yet. |
...s to keep it up to date.
this will allow our XMLRPC call for list_packages_with_serial() to execute without the insane join