Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

This page serves to provide an insight in the design of the core microservice.

As of right now I am unsure whether to put this here (GENERAL) or on the core confluence (OMSCORE), for the time being I put it here to have everything in one place, and there is not much else anyway right now.

Database

Current

The current, and considered old, database diagram. This is a direct database export using auto lay outing. Considering this is only here for historical purposes not much effort was put into this.

Due too automated generation the links between tables might be incorrect.


Diagram 1. Old database schema

OMS-CORE database old

Stripped new version - auto generated

Old database stripped from some tables which should no longer be used (or are removed because they will be added again in the future (in their own microservice)

Diagram 2. Auto generated stripped database schemaOMS-CORE database stripped

Stripped new version - edited

Some thoughts/proposals on this:

  • Rename users to members
  • There is too much overlap in fields between users and recruited users
  • It is questionable what linking organization roles to bodies directly adds.
  • The module concept is probably outdated considering the new architectural design in which the core is less monolithic
    • What is the difference between module pages and menu items?

I have not yet taken a detailed look at the fields inside the tables.

Diagram 3. Edited stripped database schema

Proposal

By Derk Snijders

Notes:

  • Styled tables are edited
  • Renamed user → member, antenna → body
  • Added Tables:
    • University
    • Address
    • body_roles
  • Removed internal_email on member
    • Add later on through separate microservice, confusing at this moment
  • Removed is_superadmin on member
  • Removed other on member
  • Not sure if suspended stuff should be directly in member
    • Maybe separate member_state table?
  • Changed all the address fields to a reference to an address object
  • Make new table study?
      • Allows users to have multiple studies, as well as linking study types and fields as well as providing ability to set its state (in progress, completed, canceled, etc.)
  • Removed recruited_users
    • I still do not really understand what this is supposed to do, but the current table has too much overlap with users.
  • Suggestion
    • Add a deleted_at field to everything, this allows is to store past relations (and provide for example an AEGEE history for members)
  • Added body_roles to allow many to many relation between body (types) and organization_roles
  • Removed is_internal and is_admin from organization roles, did not really make sense.
  • Currently having multiple roles in a body requires you to be multiple members of the body (ie. multiple body_memberships between the 2 objects in order to have multiple organization_roles)

Diagram 4. Derk's proposal

  • No labels