PostgreSQL & SQLite support

Post Reply
User avatar
jerome
Posts: 150
Joined: 29 October 2013, 08:58
Location: Marseille
Contact:

PostgreSQL & SQLite support

Post by jerome » 23 November 2015, 19:37

this is a repost of a recent message sent to the developers' mailing list.

[En]
Hi!

PostgreSQL support is untested and probably impossible with the current
code:

in libs/utils/database.cpp

bool Database::createConnection(...)
{
...
case PostSQL
:
// TODO: manage PostGre
SQL
return false;
...
}

I will delete mention of PostgreSQL in end-user documentation so as not
to mislead users about what FMF can or cannot do.

I got very little help in maintaining FMF in the last few months.
Solving even simple database issues (like issue #80, issue #66 or issue
#73) gets complicated because of SQLite and MySQL fundamental
differences (among others: single versus multiple users) and the need to
adapt code and test for both.

The single-user environment in medical practice is becoming extremely
rare and doesn't represent the future of EHR, EMR or PHR (Personal
Health Records). Even for single handed practice, using MySQL has
multiple advantages, such as speed, possibility of concurrent remote
access (remote assistant, access to database during housecalls) and the
possibility to add users in the future.

IMHO, the only useful feature of SQLite is the possibility for potential
new users to test FMF EMR quickly and easily. This could be achieved
with an "embedded MySQL server", read more about this here:
http://doc.qt.io/qt-5/sql-driver.html#qmysql

I suggest this:

1. Dropping official support of PostgreSQL. We can leave the Postgres
related code in place. If someone wants to write full PostgreSQL
support, and maintain it, it is perfect.
2. Implement embedded MySQL server feature
3. Write a SQLite -> MySQL migration tool
4. When 2 & 3 are completed, drop SQLite support

Thanks.

If you are a developer, please answer on the developers' mailing list.

Jérôme

[Fr]
Résumé en français pour les utilisateurs (pour les détails concernant les développeurs, tout est expliqué plus haut).

La pratique médicale solitaire est de moins en moins répandue. Même un soignant seul peut bénéficier du mode réseau de FMF:
* pour accéder aux données à distance (domicile du patient, domicile du soignant)
* pour travailler avec un secrétariat à distance
* en cas d'association ou de regroupement dans une structure collective

Le mode réseau n'implique pas forcément de frais supplémentaires: le serveur MySQL peut être installé gratuitement et simplement sur le même ordinateur que le logiciel FMF EMR.
Un petit cabinet qui ne souhaite pas investir dans un serveur indépendant peut utiliser un des PC déjà présents comme serveur.

Pour simplifier la maintenance du code et la résolution des bugs (et ainsi pouvoir consacrer plus de temps à faire évoluer FMF EMR avec de nouvelles fonctionnalités), je propose ceci:

1. Abandon du support de PostgreSQL (un système de bases de données similaire à MySQL) qui de toute façon n'a jamais été opérationnel
2. Offrir une version de FMF EMR avec un serveur MySQL intégré. Ainsi, pas besoin d'installer MySQL pour tester rapidement et simplement FreeMedForms en mode réseau.
3. Offrir un outil de migration de SQLite vers MySQL qui permettra aux utilisateurs du mode monoposte de transférer leurs données vers MySQL, sans modification de leurs habitudes de travail.
4. Quand les étapes 2 et 3 seront réalisées, abandon du support de SQLite.

Je déconseille donc à tout nouvel utilisateur d'installer en mode monoposte / SQLite.

Toutes vos critiques, suggestions ou questions sont les bienvenues.

Jérôme Pinguet

Post Reply