oobmigration: derive subscription account number and extract license key fields#39344
Conversation
| uuid, userID, dbutil.NewNullString(accountNumber), | ||
| uuid, userID, accountNumber, |
There was a problem hiding this comment.
If we continue inserting NULL values for subscriptions that don't have an account number, it confuses the OOB migration progress checking. Admittedly this is a shortcut, but I think it is fine, since having the account_number column NULL-able was for the sake of backward compatibility.
There was a problem hiding this comment.
We could add a column “is_migrated boolean” or something like that to circumvent it. I think it would be good practice to actually write nulls instead of empty strings, wdyt?
There was a problem hiding this comment.
Technically we could, and agree with you in general!
But frankly speaking for this particular task, I think even an OOB migration is somewhat an overkill because this only matters for the dotcom instance and I could have just written a script that writes to update the DB (but that's super risky so... OOB migration seems safer with code review and less error-prone).
I'm not incentivized enough to make this part of the migration long-lasting. 😅 WDYT?
There was a problem hiding this comment.
Is okay, I’m just thinking about when we can deprecate the migrator and how we would eventually get to 1 state for “not set” again, preferably NULL.
There was a problem hiding this comment.
Not saying that's the optimal approach, but by that time, a sync migration that does update product_subscription set account_number = null where account_number = '' would solve it 🤫 OR maybe we have migrated license management out of the dotcom (completely rewritten).
There was a problem hiding this comment.
Sounds good :) I don't believe in the latter yet, but the former satisfies me enough 😆
|
Codenotify: Notifying subscribers in CODENOTIFY files for diff fd4f511...6b7654b.
|
eseliger
left a comment
There was a problem hiding this comment.
Approving but one open question whether one of them has to be OOB and would be nice to see a test for this :)
| uuid, userID, dbutil.NewNullString(accountNumber), | ||
| uuid, userID, accountNumber, |
There was a problem hiding this comment.
We could add a column “is_migrated boolean” or something like that to circumvent it. I think it would be good practice to actually write nulls instead of empty strings, wdyt?
|
|
||
| var accountNumber string | ||
| if i := strings.LastIndex(username, "-"); i > -1 { | ||
| accountNumber = username[i+1:] |
There was a problem hiding this comment.
Since this is all the logic it takes, it feels like this migration could get away with a simple synchronous DB migration, as on prem won’t ever have entries in this table and dotcom only has a couple thousand, it doesn’t feel like unbearable load. Negative effect of an OOB
migrator is that you can never assume the data is in a certain shape until it’s been deprecated.
There was a problem hiding this comment.
Negative effect of an OOB
migrator is that you can never assume the data is in a certain shape until it’s been deprecated.
Yes, but I think this negative effect is fine in this case, the Sales data pipeline does not have this assumption (given the history of multiple broken states for license data) thus supporting continuously filling data gaps (even if this happens). 🤣
| @@ -0,0 +1,221 @@ | |||
| package productsubscription | |||
There was a problem hiding this comment.
A test for each of these would be appreciated to prove they report progress correctly (especially on non-dotcom) and to check if it properly decodes the license.
There was a problem hiding this comment.
Is there a good example of how to write the test for OOB migrations? 🙏
There was a problem hiding this comment.
Oh NVM, I think these tests should be easy to write!
There was a problem hiding this comment.
I think some of the migrators have a good test suite attached! (I know some in batches should, at least)
efritz
left a comment
There was a problem hiding this comment.
👍
@unknwon A few questions I didn't get quickly from resources in this PR:
- I'm not familiar with the tables in question here. What writes to them (in particular, are they writing only the new format according to this migration, or are they still writing an old format that must be caught by this process)?
- Does this apply only to the dotcom instance? Why (Maybe answering what fills this table also answers this question)?
All writes to them are only using the new format (changes made in the linked sister PRs), these OOB migrations only intend to deal with existing data.
Yes, only the dotcom Postgres stores product subscriptions and licenses. |
|
Thanks everyone! Merging as-is, happy to address any post-merge comments! |
This PR adds two OOB migrations:
Test plan
Manually e2e tested locally.
Part of https://github.com/sourcegraph/sourcegraph/issues/38661