-
Notifications
You must be signed in to change notification settings - Fork 7
highlevel listings dbs
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.
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"
{
"_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"
}
}
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"
}
}
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.
{
"_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
}
A "people_db" on a Listings object referrs to the people DB
Structure TBD.
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
(AKAactive_id
): String of thelisting_id
concatenated toproject_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.