Skip to content

highlevel listings dbs

Aidan Farrell edited this page Apr 1, 2021 · 3 revisions

Directory - Baked-in URL

The FAIMS app will come with a predefined couchDB URL with database name, e.g. faims3.fedarch.org:5984/directory_db Each doc in this DB is called a 'Listings Object': A name of who owns it, description, and a few host:port/db_names directing you to where the projects and people DBS are.

This doesn't even contain project names

This predefined server URL will be changeable in the app, hidden behind a settings wall, but only the most hardcore privacy nuts will want to use this.

Listings Object

Each organisation that uses FAIMS can have their own databases for their list of projects, their list of people/devices

Each 'Listings Object' allows you to contact the databases storing projects and users for the a given organisation.

A 'Listings Object' has the following:

  • "name": string, e.g. "CSIRO"
  • "description": string, e.g. "Commonwealth Scientific and Industrial Research Organisation FAIMS instance"
  • "people_db": host:port/db_name.
  • "projects_db": host:port/db_name.
  • Perhaps some description of authentication? e.g. "auth": "oauth" or "auth": "password".

If any of the above host:port/db_names are not given, they default to the corresponding host:port/db_name on a 'Listings Object' document with the id "default"

Example

{
  "_id": "fd53b824a1862bda1eb1cdb9ba004624",
  "name": "AAO Internal FAIMS instance",
  "description": "This FAIMS server is the instance used internally by the AAO for testing.",
  "people_db": {
    "host": "10.80.11.44",
    "port": 5984,
    "lan": true,
    "db_name": "people"
  },
  "projects_db": {
    "host": "10.80.11.44",
    "port": 5984,
    "lan": true,
    "db_name": "projects"
  }
}

Projects DB

The "projects_db" on a Listings object referrs to the projects DB This Project Object contains almost no information about a project. Instead, for security, it references 2 other DBs: the MetaDB and the DataDB, 2 databases that created for every project, not shared. The "_id" of a projects listing object is used by the Active Projects DB

  • When omitted, the "data_db" connection defaults to a database named "data-projects object's _id"
  • When omitted, the "metadata_db" connection defaults to a database named "metadata-projects object's _id"
{
  "_id": "lake_mungo",
  "data_db": {
    "host": "...",
    "port": "...",
    "db_name": "7h2weoniaso9" //can be named anything`
  },
  "metadata_db": {
    "host": "...",
    "port": "...",
    "db_name": "metadata-lake_mungo"
  }
}

Meta database

As well as the actual data, which is read-write by anyone part of the project, there exists the meta database. This DB is has multiple different types of document, differentiated by a prefix of the "_id". This database is for 1 project only.

Example: "example.org/data-lake_mungo"

{
  "_id": "ui-spec-A8971C281279FE8189DE27D3"
  // UI Specification 1
}
{
  "_id": "ui-spec-18927FAE67AF09A8EC7A6D89"
  // UI Specification 2
}
{
  "_id": "people",
  "people": [
    "user-id-1",
    "user-id-2"
  ]
}
{
  "_id": "schema-0AAAFCADFCA3FC12FAFDCD659A6"
  // Project schema 1
}

People DB

A "people_db" on a Listings object referrs to the people DB

Structure TBD.

Active projects - Client side

On the client-side of things, clients need to keep track of what projects they're part of, (and device credentials are stored in this database for convenience, too)

To do this, they have a active projects database, not synced to anything.

This list is essentially an instance/project pair. Specifically, each doc has:

  • Device login information (username, password). This should be the same for all active projects on the same instance
  • listing_id: _id of a doc from the directory (A Listings Object's _id)
  • project_id: _id of a doc from the "projects_db" (From Projects DB)
  • _id (AKA active_id): String of the listing_id concatenated to project_id

For every instance with an active project, the client has databases named projects/${instance_id} and people_${instance_id}, holding the project schemas, people data.

And for every active project itself, the client has a database named project/${active_id}, holding the actual data.