Skip to content
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

Setup SQL and Hookup User Model #5

Open
8 tasks done
Deon opened this issue Nov 7, 2016 · 8 comments
Open
8 tasks done

Setup SQL and Hookup User Model #5

Deon opened this issue Nov 7, 2016 · 8 comments

Comments

@Deon
Copy link
Member

Deon commented Nov 7, 2016

A few things:

  • DB Design for Users
  • Some SQL server needs to be setup
  • Add some library to interface with it
  • Hook that up to the User model.
  • Add Migrations Library
  • Add Migrations
  • Add a DB Mock Library
  • Update tests for the User model

This can be broken out into multiple tasks

@Deon Deon mentioned this issue Nov 8, 2016
@Deon
Copy link
Member Author

Deon commented Nov 8, 2016

User Table draft, based off of the current Mongoose Schema:

Also added a friends and friends request table. Please comment with suggested changes. I'll update this comment directly with changes.

CREATE TABLE users IF NOT EXISTS (
  id INT UNSIGNED AUTO_INCREMENT NOT NULL,
  password CHAR(60) NOT NULL,
  email VARCHAR(255) UNIQUE NOT NULL,
  username VARCHAR(255) UNIQUE,
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
  updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, 
  password_reset_token BINARY(32),
  password_reset_token_expiry TIMESTAMP,
  PRIMARY KEY(id)
);
CREATE TABLE friends IF NOT EXISTS (
  requestor INT UNSIGNED NOT NULL,
  requestee INT UNSIGNED NOT NULL,
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
  updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  accepted BOOLEAN NOT NULL,
  PRIMARY KEY(requestor, requestee),
  FOREIGN KEY(requestor) REFERENCES users(id),
  FOREIGN KEY(requestee) REFERENCES users(id)
);

CREATE INDEX friend_accepted ON friends(accepted);

@Deon
Copy link
Member Author

Deon commented Nov 8, 2016

Alternatively, we can merge friends/friend_requests into one and add a state enum (I think this is cleaner?).

Also, open to changes on friends key names.

@yucombinator
Copy link
Contributor

Yeah we should merge them. Also do we need a requestor / requestee distinction? Or user1/user2 would be fine.

@Deon
Copy link
Member Author

Deon commented Nov 8, 2016

IMO yes b/c then we can distinguish between friend requests you've made, and requests others have made (at least it's more descriptive)

@yucombinator
Copy link
Contributor

We can keep it that way (but I think in terms of UI we won't show anything differently once the request is accepted)

@Deon
Copy link
Member Author

Deon commented Nov 9, 2016

Agreed with the UI post-acceptance.

@Deon
Copy link
Member Author

Deon commented Nov 9, 2016

Updated DB design to reflect table merge, added index on acceptance.

@yucombinator
Copy link
Contributor

👍

Deon added a commit that referenced this issue Nov 12, 2016
Add libraries for DB + Setup new run scripts, mark tests as pending - resolution in a future PR (#5)
This was referenced Nov 12, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants