Database Structure

This page describes data structures in detail.

Please note that getters and setters should be used as much as possible. This should establish a concrete internal API that will be used and would enforce a good practices of working with data.

Agreements

1. Each schema should have created and updated dates (first one is read only and should not be changed).
2. Each schema should define a custom JSON representation for itself (this makes sense in case of an API, as it would always give the same representation that would have fine-grained control over what is exposed).
3. Using virtual attributes (virtuals) is not forbidden, although should not be used as a way of setting values. This would make things more complicated than they need to be.

Models

User

• _id - Unique internal identifier (Objectid)
• username - Unique user name (String)
• password - Hashed password representation, using Bcrypt (String)
• name
  • first - First name of a user (String)
  • middle - Middle name of a user (String)
  • last - Last name of a user (String)
• email - Unique email address (String)
• gender - user gender (Number) | according to ISO/IEC 5218
• isAdmin - Admin role flag (Boolean)
• isActivated - Is user account activated flag (Boolean)
• isBlocked - Is user account blocked flag (Boolean)
• created - Creation date (Date) | read only
• updated - Update date (Date)
• lastLogin - Last login time (Date)

Virtuals

• fullname = first + middle + last (add spaces as needed, sip middle if missing)

TODO Need to determine how to add connections to social-login possibilities. Probably some unique identifiers with some additional information as part of the object. Quite a few of the data shown here should not be part of the object JSON string representation and should never be exposed by the database (simplest example should be the password field).