Overview

This section explains the overall architecture used by the various applications.

Each application has a short name which is used in URLs, database schema names, database role names, python package names, Java package names, directory names, script names, and anywhere else an application needs to be specified unambiguously.

Profile

The main documentation page for each application contains a “Profile” section which explains the basic information concerning the database objects related to the application, as well as the application’s relations to other applications. The rest of this section explains the meanings of the main headings within the “Profile” for each application.

Schemas

Generally, all data are stored in a single PostgreSQL database. Application programs are designed to connect to the database and read/write all information from there. For testing purposes, alternate instances of the database can be used.

Each application has its own PostgreSQL database schema. In some cases applications will have additional schemas depending on their needs. The main schema is named _[appname]. Additional schemas are named _[appname]_[name] where [name] is an appropriate name.

Roles

Each application has several PostgreSQL database roles. Database objects which are part of the application have permissions granted only to the application’s own roles. Permissions for other applications or individuals to have access are handled by granting role memberships appropriately. An application role name is of the form _[appname]_[name] where [name] is an appropriate name.

There are a few standard role names common to many applications:

  • _[appname]_core — Role which owns functions and has full access to tables, including INSERT, UPDATE, DELETE, and TRUNCATE privileges. Normally, any SECURITY DEFINER functions will run as this role. Note that conceptually functions really ought to be owned by _[appname]_root but then security definer functions would run as that role. Only security definer functions actually need to run as (and therefore be owned by) _[appname]_core but for simplicity this role owns all functions.
  • _[appname]_references — Role which has REFERENCES permissions on all tables. Intended to be granted to other applications’ _root roles in order to allow them to make FOREIGN KEY references to tables in this application.
  • _[appname]_root — Role which owns all tables and therefore has full permissions to make changes, including schema changes.
  • _[appname]_select — Role which has full SELECT access to tables. Intended to grant appropriate users or other applications the ability to see all data related to the application.
  • _[appname]_ui — Role which runs user interface, typically a Web program. Typically is a member of _[appname]_select and has execute access to appropriate security definer functions and/or whatever table insert/update/delete privileges are required.

Dependencies

Each application may depend on other applications. These are listed and linked from this section of each application’s profile.

Dependents

Each application may have other applications that depend on it. These are listed and linked from this section of each application’s profile.

Details

The main documentation page for each application contains a “Details” section which links to pages explaining any additional details about the way the application works. This section provides links to additional information about the way the overall system works.

  • Architecture — Overall architecture.
  • Coding Standards
    • Python — Standards related to application code written in Python.
    • Java — Standards related to code written in Java.
    • SQL — Standards related to schema definitions, including stored procedures.
  • Version Control — Layout of the Version Control repository.
  • Database Server — About the database server.
  • Web Server — About the web server.
  • Deploy Process — About the deploy process.
  • Vagrant — About Vagrant setup.