Nel passaggio dalla versione 1.x alla 2.0, molte sono le novità architetturali introdotte in Konga, poco visibili all’utente comune ma che speriamo siano gradite agli utenti più smaliziati con background tecnico; l’effetto finale è comunque un Konga più performante rispetto al passato e pronto ad affrontare meglio il futuro. Esaminiamo di seguito queste novità.

Campi DECIMAL

Nella versione 1.x di Konga, tutti i valori decimali erano salvati nei database SQL come valori interi moltiplicati per un milione; questo voleva dire che per rappresentare il valore 1.0, nel DB veniva salvato un valore BIGINT uguale ad 1000000. Questo sia per garantire calcoli esatti fino alla sesta cifra decimale, sia perché SQLite nativamente gestisce solo certi tipi di dato standard SQL tra cui non è compreso il tipo DECIMAL – al contrario di MySQL che, come molti altri motori di database, supporta questo tipo di dato senza problemi. Se avessimo usato i DECIMAL in Konga sin dall’inizio sarebbe stato più semplice interfacciare i dati di Konga con terze parti e manipolare i dati manualmente, ma tutti gli utenti che avessero usato SQLite come driver di database avrebbero potenzialmente avuto problemi di arrotondamento nei calcoli a virgola mobile. Per ovviare a questo limite architetturale, in Konga 2.0 il driver SQLite è stato migliorato significativamente aggiungendo il supporto ai campi DECIMAL in emulazione, e questo ha consentito di poter convertire tutti i valori numerici dei DB in valori DECIMAL esatti senza rischio di avere i problemi di arrotondamento sopra menzionati.

Timestamp al millisecondo

Fino a Konga 1.x, tutti i timestamp salvati nei database erano precisi solo al secondo. In Konga 2.0 la precisione è adesso al millisecondo; il vantaggio principale è di assicurarsi che se ci siano state modifiche molto ravvicinate ad una stessa scheda da parte di due utenti diversi, adesso si può vedere chi effettivamente ha fatto la modifica prima e chi dopo.

FTS solo su filesystem e nuovo motore basato su Lucene++

In Konga 1.x era possibile decidere a livello di database se salvare l’indice delle ricerche full-text su filesystem o sul database stesso; nel secondo caso venivano usate tabelle dedicate per emulare il filesystem all’interno del database SQL. Il vantaggio di avere l’indice dentro il DB voleva essere di avere sempre l’indice che viaggiasse insieme al DB (e questo voleva dire che sia i dati che l’indice erano nello stesso file .edb se si usava SQLite); questo approccio aveva però due serie controindicazioni: appesantiva molto il database sia in termini di dimensioni che di velocità, e causava sporadicamente la corruzione dell’indice che andava pertanto rigenerato di tanto in tanto, con conseguente rallentamento delle operazioni. In Konga 2.0 si è deciso di rimuovere completamente la possibilità di salvare l’indice all’interno del database, lasciando solo il filesystem come possibilità di archiviazione. Inoltre è stato cambiato il backend del motore di ricerca full-text, sostituendo la libreria CLucene (ormai deprecata da anni) con la più moderna ed aggiornata Lucene++, conferendo maggiore stabilità dell’indice e ovviando alla corruzione dei dati di ricerca di cui soffriva CLucene.

Crittografia dei dati sensibili

Nella vecchia versione di Konga era già prevista la crittografia dei dati sensibili come email o numeri di telefono, ma questa avveniva a livello di logica del server anziché a livello SQL, causando l’impossibilità di fare ricerche o ordinare correttamente i dati in base ai campi crittografati. In Konga 2.0 la crittografia avviene a livello SQL tramite le funzioni AES (native su MySQL, in emulazione su SQLite), e questo consente sia alle ricerche che agli ordinamenti (che usano i costrutti LIKE e ORDER BY di SQL) di funzionare correttamente.

asyncio

Mentre tutti i cambiamenti architetturali finora menzionati sono stati applicati alla parte server C++ di Konga 2.0, anche la parte client ha visto un cambiamento che forse è il più significativo (e quello che ha sicuramente richiesto lo sforzo maggiore sia in termini di tempi di sviluppo che di controllo qualità) nel passaggio alla versione 2.0: tutto il codice Python della parte client è stato sottoposto ad un importante refactoring per cambiare da paradigma sincrono ad asincrono (tramite modulo standard Python asyncio integrato per l’occasione sia con kongalib che con le nostre librerie interne di gestione UI). Questo ha portato a maggiore stabilità, ad una pulizia generale del codice e maggiore manutenibilità dello stesso per il futuro, nonché alla correzione di tutta una serie di problemi legati all’architettura precedente che sarebbero stati estremamente difficili da risolvere con il vecchio paradigma.