central db settings

[paolap]

There are implications on using a centralised access.db included as part of the package data. Once there will be a central installation on the server anyone will be able to query this same database. However, the package has some commands in the "mopdb" module that can write to the database. We still need to make sure all implications of this happening are taken into account.

• random user will be able to read but not write
• user/s with writing access to db could potentially overwrite current centralised db Pros
  • any update of db is immediate
  • no need to update repo and create new release Cons,
  • risk of conflict with two authorised users updating at the same time
  • risk of conflict if someone is accessing to write and someone else to read?
  • changes to db aren't tracked
  • accidental overwriting

I think cons surpass pros, so we should find a way to update db separately from repo, which then would allow to create new releases only for db, once updates to db has been tested and confirmed to be safe Looking at https://dbhub.io as an example

In the meantime, to do:

• if user doesn't pass db name than some mopdb commands are disabled (cmor, map and del) as they all write to db.
• to allow user to augment/update central db for their own use, if db name is not passed tool should print out path of db in use. This allows them to create their own copy easily

Applying this still leaves a "hole": if a "manager" really wants to update db quickly without new release, all they need to do is to pass the path of central db via --dbname (is this desirable?)

[paolap]

This is now implemented, it can certainly be improved, and still have to test alternative to code repo to store database. DBhub might not yet have implemented the version control, as an alternative we could store the sql dump:

https://stackoverflow.com/questions/33809881/whats-a-good-way-or-tool-to-version-control-a-sqlite-database-schema-only or fossil:

https://fossil-scm.org/home/doc/trunk/www/index.wiki

[paolap]

From sqlite 3.0 documentation, in regard to to write lock: "SQLite version 3.0 allows one process to begin writing the database while other processes continue to read. The writer must still obtain an exclusive lock on the database for a brief interval in order to commit its changes, but the exclusive lock is no longer required for the entire write operation"