Skip to content

Drop Email column (merge and deploy the fix for #1888 first!) #1891

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 9 commits into from
Dec 2, 2019

Conversation

mugoh
Copy link
Contributor

@mugoh mugoh commented Nov 12, 2019

Fixes #1889

This cleans up the uses of the field email from User by:

  • dropping the email field from User
  • clearing references to the dropped email field
  • migrating and updating the schema changes

@rust-highfive
Copy link

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @carols10cents (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

@mugoh
Copy link
Contributor Author

mugoh commented Nov 12, 2019

How should the test database visibility configuration be updated after modifying the schema?
It fails with:

---- tasks::dump_db::gen_scripts::tests::check_visibility_config stdout ----
thread 'tasks::dump_db::gen_scripts::tests::check_visibility_config' panicked at 'The visibility configuration does not match the database schema:
Column users.email does not exist in the database.', src/tasks/dump_db/gen_scripts.rs:204:9

@mugoh mugoh force-pushed the drop_email_column branch from 5be765d to afa3641 Compare November 13, 2019 13:31
@carols10cents
Copy link
Member

How should the test database visibility configuration be updated after modifying the schema?
It fails with:

---- tasks::dump_db::gen_scripts::tests::check_visibility_config stdout ----
thread 'tasks::dump_db::gen_scripts::tests::check_visibility_config' panicked at 'The visibility configuration does not match the database schema:
Column users.email does not exist in the database.', src/tasks/dump_db/gen_scripts.rs:204:9

Removing the users.email line from the dump-db.toml file should do it. The dump-db.toml file is configuration for the public database dumps we make, and this test ensures the database schema is always in sync with this configuration so that we don't accidentally leak data.

I'll make the error message for that test a bit clearer to point at what needs to be done.

@mugoh mugoh force-pushed the drop_email_column branch from afa3641 to 3544b91 Compare November 13, 2019 14:09
- `do_nothing` on `emails` insertion violates unique
constraint on `user_id`
@mugoh
Copy link
Contributor Author

mugoh commented Nov 13, 2019

Thanks @carols10cents! That sorted it out.
Dumping to the emails table originally required the user: email column - what would be the reason for getting a unique key violation on emails: user_id after dropping the users: email column.

INSERT INTO emails (user_id, email)
SELECT id, email FROM users WHERE email IS NOT NULL;

@carols10cents
Copy link
Member

Dumping to the emails table originally required the user: email column - what would be the reason for getting a unique key violation on emails: user_id after dropping the users: email column.

I'm confused, are you getting a unique key violation? Can you give me steps to reproduce?

@carols10cents
Copy link
Member

Oh I see the errors in travis now. Investigating!

Copy link
Member

@carols10cents carols10cents left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some comments that should help you get past the test failures! Please let me know if you have more questions!

@@ -0,0 +1,2 @@
-- Your SQL goes here
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can remove this comment :)

@@ -0,0 +1,2 @@
-- Your SQL goes here
ALTER TABLE users DROP COLUMN email CASCADE;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is super picky, but can you remove the extra space between TABLE and users?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:)

@@ -38,10 +38,10 @@ pub fn me(req: &mut dyn Request) -> CargoResult<Response> {

let verified = verified.unwrap_or(false);
let verification_sent = verified || verification_sent;
let user = User { email, ..user };
let user = User { ..user };
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this line can be completely removed now, actually! I think user = User { ..user } is doing a no-op.

email_verified: bool,
email_verification_sent: bool,
) -> EncodablePrivateUser {
) -> CargoResult<EncodablePrivateUser> {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you explain why this function needed to be changed to return a Result? It doesn't look like it's necessary to me because I don't see anywhere returning an Err variant. Am I missing something?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It isn't necessary. I was previously reading this email variable from the database with an Err

if let Some(user_email) = email {

variant result before realizing that was already "done" and the email could simply be passed to the src/models/users/encodable_private function as an argument.
I definitely forgot to undo that modification to the return type - will do so now

pub gh_access_token: String,
pub gh_login: String,
pub name: Option<String>,
pub gh_avatar: Option<String>,
pub gh_id: i32,
}

/// Represents a new user record insertible to the `users` table
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Small fix: can you change insertible to insertable in this comment please?

user.email = Some(email.to_string());
let email = "[email protected]";
let user = crate::new_user(username)
.create_or_update(Some(email), conn)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aha, so the unique constraint that's causing the tests to fail is that here in the test setup you're creating a new user with an email set, then lines 142-149 right after this the test setup is inserting the email into the table directly, which violates the constraint we have that each user may only have one email.

To fix this, you can pass None to create_or_update here and the next part will take care of inserting the email (and setting it to verified, which is important for the tests).

- retain email registered with when github email is modified
Copy link
Member

@carols10cents carols10cents left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just one question, thanks!

@@ -510,12 +514,13 @@ fn test_confirm_user_email() {

// Simulate logging in via GitHub. Don't use app.db_new_user because it inserts a verified
// email directly into the database and we want to test the verification flow here.
let email = "cow@mammals@milk";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm curious, why is the value different here? Any particular reason, and any reason why it's not a valid email address (two @s)?

@mugoh
Copy link
Contributor Author

mugoh commented Nov 16, 2019

Resolved. The invalid email address was a mistake I hadn't noted

@carols10cents
Copy link
Member

carols10cents commented Nov 18, 2019

Thank you so much!! This looks great, but I'm not going to merge it yet-- we need to merge and deploy the fix for #1888 to remove all the uses of the email column first, so that there aren't any connections using the email field when we deploy this PR.

@carols10cents carols10cents changed the title Drop Email column Drop Email column (merge and deploy #1888 first!) Nov 18, 2019
@carols10cents carols10cents changed the title Drop Email column (merge and deploy #1888 first!) Drop Email column (merge and deploy the fix for #1888 first!) Nov 18, 2019
@bors
Copy link
Contributor

bors commented Nov 22, 2019

☔ The latest upstream changes (presumably #1901) made this pull request unmergeable. Please resolve the merge conflicts.

bors added a commit that referenced this pull request Nov 26, 2019
Missed a conversion from UserNoEmailType to User

When reviewing #1911, I missed a spot. I reverted the PR merge on master, so this PR reverts the revert and adds the fix.

I tried to write a test that would have caught this, but I utterly failed at making a real-enough app/request that would have `.user()` but would let me set the `session()` :(

Also a lot of this code is temporary and will be undone once I've rebased #1891, but this needs to be deployed separately from #1891 to ensure there aren't any uses of the email column.

r? @jtgeibel
@mugoh mugoh force-pushed the drop_email_column branch 8 times, most recently from f400318 to 8a8a1d3 Compare November 27, 2019 13:02
@bors
Copy link
Contributor

bors commented Dec 2, 2019

☔ The latest upstream changes (presumably #1700) made this pull request unmergeable. Please resolve the merge conflicts.

@carols10cents
Copy link
Member

I removed some more of the temporary code that was needed to deploy the code that stopped using the email column (and that has been deployed). I also introduced more merge conflicts by merging another PR just now; I'll be fixing those in a few hours.

@carols10cents
Copy link
Member

I think this is ready to go now!! Thank you!!!

@bors r+

@bors
Copy link
Contributor

bors commented Dec 2, 2019

📌 Commit c7ac5cb has been approved by carols10cents

bors added a commit that referenced this pull request Dec 2, 2019
Drop Email column (merge and deploy the fix for #1888 first!)

#### Fixes #1889

This cleans up the uses of the field `email` from `User` by:
- dropping the `email` field from `User`
- clearing references to the dropped email field
- migrating and updating the schema changes
@bors
Copy link
Contributor

bors commented Dec 2, 2019

⌛ Testing commit c7ac5cb with merge dbe39ae...

@bors
Copy link
Contributor

bors commented Dec 2, 2019

☀️ Test successful - checks-travis
Approved by: carols10cents
Pushing dbe39ae to master...

@bors bors merged commit c7ac5cb into rust-lang:master Dec 2, 2019
This was referenced Dec 2, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Cleanup: drop the email column on the users table
4 participants