Note di rilascio

Sono state apportate migliorie al funzionamento di uno strumento interno, il cui scopo è quello di individuare attributi derivati o classi non utilizzate.

Lo strumento è accessibile da Designer nel menu Tools, selezionando la voce Find unused model elements.

Componenti interessati: Designer

Sono stati risolti i seguenti problemi derivati dal cambio di data type per un attributo:

• le informazioni di localizzazione non erano aggiornate se facevano riferimento a un tipo di dato non più supportato;

• la copia di un attributo incompatibile sollevava errori nella fase di copia delle informazioni di localizzazione.

Il nuovo comportamento è il seguente:

• se il tipo non è supportato, viene creata una nuova localizzazione preservando la label e il tooltip (che sono sempre compatibili);

• la copia avviene solo per i valori dei tipi di dato compatibili; in caso contrario, viene mostrato un errore.

Componenti interessati: Designer

I controlli di cardinalità sono stati ottimizzati in modo da attivarsi solo nei casi strettamente necessari (i.e. cardinalità finita e diversa da 0N). Questo ha comportato un aumento delle prestazioni.

Componenti interessati: Engine Framework

È ora possibile istanziare via plugin le implementazioni delle classi ApplicationMetadata per scopi di test.

Componenti interessati: Engine Framework

È stato risolto un problema per cui, se il parsing di un’espressione math individuava degli errori, veniva sollevata un’eccezione nella fase di costruzione del relativo messaggio.

Componenti interessati: Designer

È stato risolto un problema per cui l’utilizzo dell’EntitySession da plugin poteva condurre a scenari in cui le risorse allocate non erano correttamente rilasciate.

Componenti interessati: Cloudlet Framework

Sono stati effettuati degli interventi mirati a ridurre il numero di query verso il database necessarie per completare le operazioni di persistenza e validazione degli oggetti.

Componenti interessati: Engine Framework, API GraphQL

È stato risolto un problema che rendeva impossibile la start di una Cloudlet che richiedeva un upgrade.

Componenti interessati: Dashboard, Dashboard Servant

Lato Designer, è ora possibile definire messaggi di errore personalizzati, i quali verranno mostrati nella fase di accesso a una vista applicativa in GraphQL nei seguenti due casi:

• l’utente non ha un profilo autorizzato ad accedere a quella vista applicativa;
• il filtro definito sulla vista non include l’utente in questione.

In GWT, le applicazioni a cui un utente non può accedere per le ragioni sopra citate continuano a non essere mostrate nella sua home page.

Componenti interessati: Designer, Engine Builder

Non è più possibile assegnare il nome ID a un qualsiasi membro di una classe Livebase (attributo o ruolo). Farlo porta ora alla generazione di una issue bloccante, che non consente il salvataggio del modello.

Componenti interessati: Designer, Engine Builder

È stata aggiunta una nuova checkbox al pannello Edit > Preferences, all’interno della scheda Editor, che permette di attivare o disattivare le decorazioni delle icone per le voci dell’albero Schemas.

Componenti interessati: Designer

È stato risolto un problema per cui, disabilitando tutte le classi all’interno di una vista applicativa, non veniva più mostrata l’icona di warning accanto a quella della suddetta vista, all’interno dell’albero Schemas.

Componenti interessati: Designer

Sono state effettuate operazioni di manutenzione all’infrastruttura Livebase che hanno permesso di velocizzare i tempi di deploy delle API GraphQL.

Componenti interessati: Hosting Server

La necessità di correggere inconsistenze che possono verificarsi durante le operazioni di manutenzione evolutiva, relativamente all’upgrade delle classi form definite nel modello di una Cloudlet, ha portato all’introduzione di una nuova funzionalità all’interno del pannello Advanced Tools..., raggiungibile dal menu contestuale del Cloudlet Database (clic destro sull’icona): è ora possibile forzare la rimozione e la creazione ex-novo delle tabelle corrispondenti alle classi form, senza perdite di dati.

La funzionalità cancellerà tutte le tabelle relative a classi form, per poi rigenerarle al successivo avvio della Cloudlet. Se questa è già avviata, sarà arrestata e rilanciata in automatico.

Componenti interessati: Dashboard, Dashboard Servant, Hosting Servant

È stato risolto un bug grafico per cui l’icona dell’oggetto trascinato non era mostrata durante l’operazione di drag.

Componenti interessati: Dashboard

Precedentemente, era possibile creare Cloudlet anche su Hosting Server che risultavano inattivi. Adesso, questo non è più consentito: se un utente vuole creare una Cloudlet e ha accesso a più di un server, quelli attualmente inattivi sono mostrati in grigio. Se nessuno di essi è disponibile, viene mostrato un messaggio di errore.

Componenti interessati: Dashboard, Dashboard Servant

È stato risolto un problema per cui le tabelle relative alle classi form non venivano rimosse quando si richiedeva l’eliminazione del database di una Cloudlet.

Componenti interessati: Dashboard Servant, Hosting Servant

È stato risolto un problema per cui, copiando il database da una Cloudlet a un’altra tramite drag & drop, si verificavano inconsistenze nelle successive operazioni di upgrade delle classi form.

Componenti interessati: Dashboard Servant, Hosting Servant

È stato risolto un problema per cui non era possibile avere contemporaneamente un’associazione e una composizione con la classe __User come sorgente. Ciò era dovuto a un meccanismo che propagava i class filter definiti sulla classe __User ai suoi eventuali part, generando attributi derivati le cui espressioni math facevano riferimento a valori non accessibili. Intervenire sul meccanismo ha permesso di risolvere il problema.

Componenti interessati: Engine Builder

Le operazioni di allineamento di modello e database, nel caso di modifiche a carico delle classi Form, sono state ottimizzate e corrette.

Componenti interessati: Dashboard Servant, Hosting Servant

Ora il pulsante API & Public URLs () appare ingrigito se è in corso un’operazione sulla relativa Cloudlet, come una build o un avvio.

Componenti interessati: Dashboard Client

Agendo sul Localization Schema della propria Cloudlet, il modellatore può ora definire una serie di messaggi di validazione personalizzati per ogni elemento del modello. Lo scopo è quello di avere errori maggiormente focalizzati sul dominio di definizione del modello. Per il momento, questi vengono inviati solo lato server, dunque in risposta alle chiamate GraphQL e ai metodi della EntitySession.

Gli elementi del modello per cui è possibile definire messaggi personalizzati sono i seguenti:

• ruoli
  • violazione di cardinalità diretta;
  • violazione di cardinalità indiretta;
• classi
  • violazione di vincolo di unicità;
• attributi
  • violazione di vincolo required;
  • violazione di vincolo sul range di un attributo numerico;
  • violazione di vincolo sul numero di cifre decimali;
  • violazione di vincolo sulla lunghezza di un attributo stringa;
  • violazione di vincolo sui pattern ammessi per un attributo stringa;
  • violazione di vincolo sulle estensioni ammesse per un attributo file;
  • violazione di vincolo sulle dimensioni massime ammesse per un attributo file.

Componenti interessati: Designer, Engine Builder

È stato risolto il seguente problema a carico delle Editable: modificando il valore di un campo (attributo o ruolo) da cui dipendeva il dominio di associabilità di un ruolo, i relativi campi dell’Editable non erano resettati a loro volta, permettendo così associazioni inconsistenti (ad esempio: avendo due campi regione e provincia valorizzati a Lazio e Roma, modificando la regione in Lombardia il campo provincia rimaneva erroneamente valorizzato a Roma).

Componenti interessati: GWT Client

È stato risolto un problema per cui, mancando gli opportuni controlli, gli utenti potevano utilizzare le API GraphQL per invocare il FormActionHandler di una classe, anche se questa non era accessibile in base al loro Profile Schema.

Componenti interessati: API GraphQL

Sono ora disponibili le seguenti nuove funzionalità relative alla gestione dei Cloudlet Database:

• Check structure and update manufacturing plate: confronta lo schema relazionale del database allo stato attuale con quello che sarebbe generato dal modello attualmente in uso. L’intento è quello di produrre un report con le differenze e farle opportunamente gestire allo sviluppatore, specialmente se questi ha precedentemente effettuato delle modifiche alla struttura del database senza avvalersi di Livebase;
• Download update plan: genera e scarica l’update plan, ovvero un file contenente gli statement SQL necessari per allineare il database al modello attuale;
• Dump for update: effettua il dump di tutte le tabelle che verranno influenzate dall’update plan.

Per accedere a queste nuove funzionalità, è necessario selezionare l’opzione Advanced Tools... nel menu contestuale del Cloudlet Database (tasto destro sull’icona).

Componenti interessati: Dashboard Client, Dashboard Servant

È stato effettuato un raffinamento delle politiche che gestiscono lo stato di under maintenance relativamente agli account e alle Cloudlet:

• il fallimento di un’operazione a livello di account, per cui non è possibile attuare una procedura di recupero, determina il posizionamento dell’intero account in under maintenance;
• il fallimento di un’operazione in scrittura sulla singola Cloudlet, per cui non è possibile attuare una procedura di recupero, determina il posizionamento di quella sola Cloudlet in under maintenance;
• il fallimento di un’operazione in lettura o ripetibile sulla singola Cloudlet, per cui non è possibile attuare una procedura di recupero, NON determina il suo posizionamento in under maintenance.

Componenti interessati: Dashboard Servant

È stato risolto il seguente problema: un account senza Hosting Server associato che tentava di creare una Cloudlet provocava un’eccezione, e come conseguenza l’account passava nello stato under maintenance. Questo comportamento è stato modificato in modo che venga solamente sollevata l’eccezione.

Componenti interessati: Dashboard Servant, Hosting Servant

È stata effettuata la sostituzione dei vincoli NOT NULL con le clausole CHECK CONSTRAINT all’interno dei Cloudlet Database. Questa modifica ha migliorato la leggibilità delle query generate e delle prestazioni complessive del database. Inoltre, ora è possibile applicare indici alle tabelle, e l’algoritmo utilizzato per il calcolo dei valori derivati ha subito delle ottimizzazioni nelle fasi di inserimento e modifica.

Componenti interessati: Database Coder, Cloudlet Database, Database Checker, Database Updater, Engine Builder

L’operazione di Expand/Collapse dei descrittori della Cloudlet è ora interamente gestita dalla Dashboard in memoria, nel modo seguente: all’avvio, tutti i descrittori sono mostrati espansi e l’utente può collassarli o espanderli nuovamente a sua discrezione. Se la Dashboard viene chiusa, lo stato dei descrittori viene resettato.

L’operazione è stata successivamente rimossa lato server, riducendo il numero di casistiche in cui è richiesto il reserve della Cloudlet (vedi note di rilascio 5.14.4) e migliorando le prestazioni di conseguenza.

Componenti interessati: Dashboard Servant

È stata corretta la tonalità di rosso utilizzata per uno dei colori di sfondo assegnabili a un descrittore di una Cloudlet: questo ha permesso di rendere le scritte maggiormente leggibili.

Componenti interessati: Dashboard Client

È stato risolto un problema per cui il Designer andava in blocco dopo aver eseguito l’operazione di Undo o Redo.

Componenti interessati: Designer

Sono stati corretti alcuni errori che riguardavano il calcolo degli incrementi degli LCP in scenari particolari.

Componenti interessati: Designer

È stato risolto un problema per cui, importando dai modelli in libreria una classe con FormActionHandler insieme alla classe Form puntata dall’handler, il Designer subiva un crash al momento del salvataggio del modello.

Componenti interessati: Designer

Formulando una mutation di tipo updateBulk e filtrando su un array di id, questa aveva effetto solo per i primi 10 elementi specificati. Il problema era dovuto a un comportamento di default che, in assenza dell’argomento options, portava il server a ordinare tutti i record per id crescente selezionando poi solo i primi 10.

Componenti interessati: API GraphQL

È stato risolto un problema per cui, al login sulla Dashboard o al suo refresh, la conclusione delle operazioni pendenti sulle Cloudlet poteva andare in timeout sollevando eccezioni, qualora alcune di queste operazioni impiegassero troppo tempo.

Componenti interessati: Dashboard Client, Dashboard Servant

È stato risolto un problema per cui l’operazione di Expand/Collapse del descrittore delle Cloudlet, nel caso di account con sub-account, causava conflitti di concorrenza. Ciò era dovuto al fatto che l’operazione non richiedeva il reserve della Cloudlet.

Componenti interessati: Dashboard Client

Non è più disponibile la funzionalità View History, che aveva lo scopo di visualizzare lo storico delle operazioni eseguite su un Cloudlet Database. Di conseguenza, non è più presente l’opzione nel menu contestuale del database e nel relativo pannello informativo.

Componenti interessati: Dashboard Client

È stato risolto un problema per cui la modifica del percorso di un attributo query determinava sempre un incremento di LCP pari a zero.

Componenti interessati: Designer

I parametri del connection pooler, resi disponibili per la configurazione lato dashboard dalla versione 5.11.9, sono ora esposti anche tramite il servizio REST /auth/administration/dataSourceStatus.

Il servizio restituisce ora strutture dati in formato JSON o xml, con i seguenti nuovi campi:

boolean autoCommit;
long connectionTimeout;
long idleTimeout;
long maxLifetime;
String connectionInitSql;
long validationTimeout;
long leakDetectionThreshold;
int maxPoolSize;
boolean allowPoolSuspension;
boolean readOnly;
String transactionIsolation;

Componenti interessati: Cloudlet Framework

Rilassando un vincolo di cardinalità su un ruolo, non viene più eseguito il relativo controllo all’interno dei Cloudlet database. Come risultato, sono stati ridotti i tempi complessivi di esecuzione delle verifiche di allineamento tra modello e database.

Componenti interessati: Database Checker

Considerando che lo stop di una Cloudlet è un’operazione che può causare disservizi per i suoi utenti finali, viene ora mostrato un popup che richiede una conferma prima della sua esecuzione.

Componenti interessati: Dashboard Servant

L’avvio di una Cloudlet provocava la rimozione e rigenerazione di tutte le tabelle relative alle classi form definite nel modello, anche se non erano state fatte modifiche a loro carico.

Sono state dunque introdotte opportune strategie, in modo da ottenere rigenerazione delle sole tabelle relative alle classi form che sono state modificate nell’attuale versione del modello.

Componenti interessati: Dashboard Servant

È stato risolto un problema per cui, in determinate situazioni, l’operazione di reserve di una Cloudlet impiegava un tempo eccessivo, anche dell’ordine di diversi minuti.

Componenti interessati: Dashboard Servant

È stato risolto un problema per cui, al momento del login sulla Dashboard, l’operazione di connessione alle Cloudlet (segnalata dal messaggio Please wait while connecting to cloudlet) poteva impiegare tempi eccessivi. Questo è stato risolto introducendo opportune strategie di caching delle informazioni.

Componenti interessati: Dashboard Servant

I messaggi per la segnalazione delle issue del modello, mostrati nella status bar del Designer, sono stati diversificati in funzione della severità:

• per le issue di bassa gravità, di tipo info, il messaggio è ora This model has minor issues (no action required)
• per le issue di media gravità, di tipo warning, il messaggio è ora This model has warnings you must fix before saving
• per le issue di alta gravità, di tipo error, il messaggio è ora This model has errors you must fix before saving

Componenti interessati: Designer

È stato risolto un problema per cui il comando Set state of all elements > Enabled/Disabled, accessibile dal menu contestuale delle viste applicative, agiva anche sugli elementi delle classi che non potevano essere disabilitati.

Componenti interessati: Designer

È stato aggiunto un nuovo task denominato checkEngineDatabaseMismatch al plugin Gradle: la sua esecuzione permette di individuare le issue di disallineamento tra l’engine caricato sulla Cloudlet e il suo database.

Componenti interessati: Livebase Gradle Plugin

È stato complessivamente migliorato il throughput risultante dall’utilizzo dell’operatore in, utilizzabile sia nella costruzione di espressioni math da Designer, che nella formulazione di filtri in chiamate GraphQL.

Componenti interessati: Engine Framework (Expression Parser)

È stato complessivamente migliorato il throughput delle richieste GraphQL annidate: nel caso in cui ci sia una sola nidificazione, le query SQL necessarie a recuperare gli oggetti “figli” usano ora come condizione di filtraggio l’uguaglianza anziché l’operatore in come avviene per tutti gli altri casi.

Componenti interessati: API GraphQL

È stato risolto un problema per cui, avendo un modello che presenta una catena di attributi query a cardinalità 1 verso l’attributo di piattaforma __id, venivano sollevati errori a runtime durante la validazione degli oggetti salvati.

Componenti interessati: Engine Framework (Runtime Query Generator)

È stato risolto un problema per cui se avvenivano invocazioni annidate di handler (es. persistence handler), quella di livello più basso sovrascriveva le impostazioni di applicationValidationLevel e applicationVetoLevel stabilite dal livello più in alto, riportandole ai valori di default.

Componenti interessati: Cloudlet Framework

Le proprietà del connection pooler, disponibili nell’omonima scheda del pannello di configurazione della Cloudlet, mostrano ora i propri valori di default qualora non siano state modificate. Per ogni proprietà è stato anche introdotto un pulsante che permette di resettare i valori impostati.

Componenti interessati: Dashboard Client

Per rendere l’operazione di start dei plugin maggiormente resistente agli errori, sono state operate delle modifiche alla gestione del loro ciclo di vita per consentire la start solo dopo che è stato effettuato il deploy dell’engine.

Componenti interessati: Dashboard Client

Per ridurre i tempi di avvio delle Cloudlet, la procedura di rebuild delle API GraphQL è stata modificata per essere effettuata solo nelle seguenti condizioni:

• l’engine della Cloudlet ha subito un redeploy;
• le API GraphQL non sono mai state generate o sono state rimosse;
• il builder delle API ha subito un aggiornamento.

Componenti interessati: Dashboard Servant

È stato risolto un problema che determinava il lancio di un’eccezione all’apertura del pannello di dettaglio del Cloudlet database, facendo clic sulla relativa icona all’interno del descrittore. Ciò era dovuto all’esistenza di alcuni scenari in cui il codice che governa l’interfaccia utente non riusciva ad individuare il pannello da aprire al clic sull’icona.

Componenti interessati: Dashboard Client

È stato risolto un problema per cui, se si verificava un fallimento durante l’operazione di avvio di una Cloudlet, fallivano anche le successive procedure di recupero dell’errore. La causa era dovuta al fatto che venivano effettuate modifiche su oggetti dichiarati immutabili.

Componenti interessati: Dashboard Servant

Non è più disponibile la voce Class menu > Convert to singleton, che consentiva di trasformare una normale classe in Singleton.

Componenti interessati: Designer

È ora disponibile pubblicamente un plugin Gradle che consente agli sviluppatori di interagire programmaticamente con Livebase nell’ambito di un progetto Gradle, e gestirne il ciclo di vita dei propri modelli, Cloudlet e Plugin mediante task Gradle (ad esempio: avviare / fermare / aggiornare una Cloudlet esistente o le sue API GraphQL, installare un modello su una Cloudlet, scaricare un modello o il suo SPI dalla libreria, installare e avviare un Plugin su una Cloudlet…).

Il progetto e la relativa documentazione (al momento disponibile solo in lingua inglese) sono disponibili alla seguente repository: fhostercom/livebase-gradle-plugin, mentre la dipendenza Gradle è disponibile su Maven Central Repository.

Componenti interessati: Livebase Gradle Plugin

È stato risolto un problema per cui l’utente che effettuava la chiamata poteva compiere introspezione degli schema GraphQL di endpoint relativi alle viste applicative per le quali non era abilitato. Questo comportamento si verificava anche nel client GraphiQL: cambiando endpoint, l’utente autenticato poteva esplorare la documentazione anche degli endpoint per i quali non era autorizzato.

La soluzione è consistita nell’includere, nel controllo dei permessi di accesso (grant) alle viste applicative, anche le query verso i servizi __schema e __type. Attualmente resta possibile visionare da GraphiQL l’elenco (e i nomi) di tutti gli endpoint della Cloudlet, anche se l’utente non ha più accesso alla documentazione dello schema.

Componenti interessati: API GraphQL

Contestualmente all’intervento appena descritto, per maggiore chiarezza è stato rinominato il valore APPLICATION_GRANT dell’enum IssueType in APPLICATION_ACCESS_FORBIDDEN. La semantica del tipo di Issue resta invariata (maggiori informazioni disponibili qui)

Componenti interessati: API GraphQL

È stato risolto un problema di aggiornamento del descrittore di una Cloudlet, che continuava a mostrare l’etichetta Please wait e il pulsante API disabilitato anche dopo il termine dei preparativi.

Componenti interessati: Dashboard Servant

Sono state rese asincrone le operazioni di creazione di nuovi modelli in libreria e di installazione dei modelli sulle Cloudlet; questo consente di evitare lo scadere della sessione negli scenari in cui queste operazioni richiedono tempi di completamento elevati.

Componenti interessati: Dashboard Servant

È stato risolto un problema per cui, durante il caricamento iniziale delle Cloudlet in seguito al login, l’elenco di queste era centrato automaticamente sulla prima Cloudlet caricata, invece che sulla prima dell’elenco.

Componenti interessati: Dashboard Client

Il supporto alle ontologie è stato rimosso: non è più possibile definire ontologie all’interno di un modello e, nel caso venga aperto un modello che le presenta, vengono rimosse automaticamente previa comparsa di un warning.

Componenti interessati: Designer

L’overload accetta un numero variabile di oggetti PersistCommand che rappresentano uno o più comandi da eseguire al momento della persistenza della sessione, usando come contesto la connessione impiegata dalla relativa transazione.

In questo modo, è possibile persistere in modo transazionale anche quelle modifiche che non interessano esplicitamente gli oggetti manipolati nella sessione, come ad esempio operazioni CRUD su altre tabelle del Cloudlet Database.

interface EntitySession {
  //...
  persist(PersistCommand... commands)
}

Componenti interessati: Engine Framework (SPI)

Sono stati eseguiti degli interventi al processo di validazione dei ruoli di associazione, il cui risultato è stata una riduzione dei tempi di salvataggio degli oggetti all’interno di una sessione di lavoro.

Gli interventi sono consistiti nel ridurre il numero di query necessarie a ottenere la persistenza, nel caso di modifiche fatte direttamente su un ruolo (aggiunta e rimozione di oggetti associati), o provocate dalla rimozione di oggetti che possiedono associati (verifica della cardinalità minima).

Componenti interessati: Engine Framework

Sono state introdotte delle ottimizzazioni nell’algoritmo di fetch GraphQL: in particolare, è stato ottimizzato il processo di costruzione delle query SQL a partire da una richiesta GraphQL attraverso l’eliminazione di statement ridondanti.

Componenti interessati: API GraphQL

Al fine di facilitare l’integrazione del servizio di health check con servizi e sistemi esterni alla Cloudlet, l’endpoint REST che espone tale funzionalità è stato spostato sull’endpoint pubblico <CloudletUrl>/public/administration/healthcheck. Il servizio è pertanto accessibile senza bisogno di fornire credenziali.

Componenti interessati: Cloudlet Framework

Sono stati rimossi i package bean e mock dallo SPI dei plugin, che erano stati dichiarati deprecati nel rilascio della versione 5.9.1.

Package rimossi:

com.fhoster.livebase.cloudlet.bean
com.fhoster.livebase.cloudlet.mock

Classi e interfacce rimosse:

com.fhoster.livebase.cloudlet.ImmutableEntityProvider
com.fhoster.livebase.cloudlet.Session
com.fhoster.livebase.cloudlet.CloudletSessionFactory
com.fhoster.livebase.cloudlet.CloudletMemberManager
com.fhoster.livebase.cloudlet.CloudletMember
com.fhoster.livebase.cloudlet.BeanIdentifier

Componenti interessati: SPI Plugin

Per evitare disservizi sperimentati successivamente alla sua rimozione, è stata reintrodotta nello SPI la classe deprecata DataValidationFailure.

Componenti interessati: Engine Framework (SPI)

È stato risolto un problema per cui il conteggio dei byte di un modello caricato sulla Dashboard veniva mostrato raddoppiato.

Componenti interessati: Dashboard Client

Nel pannello informativo della Cloudlet API & Public URLs , è stato rimosso lo switch che abilitava la generazione delle API REST dalla scheda API, terminando di fatto il supporto alla generazione delle vecchie API REST deprecate. Sono stati rimossi anche tutti i servizi di visualizzazione dell’URL degli endpoint presso cui accedere a queste API.

Componenti interessati: Dashboard Client, Dashboard Servant

Il controllo dei Selection Filter e dei Selection Path, necessario per determinare l’associabilità di un oggetto satellite, viene ora eseguito sia dal client generato per le Cloudlet che lato server. Questo consente di risolvere alcuni problemi riscontrati nell’utilizzo dei servizi GraphQL, in particolare durante la configurazione dei parametri di invocazione dei FormActionHandler e nel salvataggio di oggetti aventi vincoli di associabilità.

Componenti interessati: Engine Builder

È stato risolto un problema relativo alla mappatura delle eccezioni lanciate da FormActionHandler invocati mediante gli appositi servizi GraphQL: in caso di errori esplicitamente sollevati dal codice del Plugin mediante HandlerException, il server restituiva una risposta contenente un errore generico, determinando la perdita di tutte le informazioni diagnostiche incluse nel codice del Plugin. Questo accadeva perché le eccezioni venivano rilanciate come HandlerInvocationException e subivano un’intercettazione prima di giungere al sottosistema GraphQL.

Componenti interessati: API GraphQL

È ora possibile assegnare colori personalizzati ai descrittori delle Cloudlet. Questo consente agli utenti di distinguerle in base a diversi criteri, quali ad esempio l’ambiente di operatività (produzione, validazione, test, etc…). Questa funzione è inclusa nel menu contestuale delle Cloudlet: passando il mouse sulla voce Background comparirà un menu dal quale scegliere un colore per il relativo descrittore.

Componenti interessati: Dashboard Client

È ora possibile configurare il connection pooler direttamente dalla Dashboard, senza dover agire sul database.

Per farlo è necessario accedere al pannello di configurazione della Cloudlet, attraverso la voce Configure... presente nel suo menu contestuale. Il suddetto pannello presenta una nuova scheda denominata Connection pooler, la quale contiene una tabella con due colonne:

• Property, contenente gli identificatori delle proprietà del connection pooler;
• Value, contenente i valori per ciascuna proprietà.

L’utente può effettuare modifiche alla configurazione cliccando sulle celle della colonna Value.

Componenti interessati: Dashboard Client, Hosting Servant

È stato risolto un problema osservato nel caso di account Livebase con subordinati: precedentemente, se un utente A riservava la modifica del modello utilizzando il pulsante EDIT nel Designer mentre un utente B aveva già eseguito delle modifiche in maniera concorrente, il modello non rifletteva nessuna delle modifiche operate da B. Ciò era dovuto al fatto che le operazioni di lock sui modelli non tengono conto delle versioni disponibili in un dato istante, e le successive operazioni di aggiornamento confrontano i timestamp lato client e lato server per la sola versione che si desidera modificare.

La soluzione è consistita nell’introdurre un controllo che impedisce la modifica di un modello da parte di un utente se la versione presente localmente non è la più recente (il modello è accessibile unicamente in sola lettura): l’utente dovrà chiudere il Designer ed effettuare un aggiornamento della Dashboard.

Componenti interessati: Dashboard Servant

Sono state rimosse le funzionalità relative al backup delle Cloudlet: il menu contestuale non comprende più l’opzione Backup.

Componenti interessati: Dashboard Client, Dashboard Servant, Hosting Servant

È stata aggiunta la possibilità di richiedere le informazioni di insight per i servizi GraphQL di tipo Mutation aventi una componente di lettura dei dati: ciò avviene attraverso l’aggiunta dell’argomento opzionale insight già utilizzato per i servizi Query (maggiori informazioni disponibili qui). Considerando che queste informazioni permettono di analizzare facilmente le strategie di ottimizzazione adottate dal framework in termini di query SQL eseguite, si è infatti ritenuto utile prevederle anche nell’ambito delle Mutation.

Componenti interessati: Runtime Query Generator

Sono stati rimossi i controlli di esistenza precedentemente effettuati durante le operazioni di gestione dei lock nelle Cloudlet, considerati non necessari. Questo ha prodotto un miglioramento delle prestazioni complessive in quanto i suddetti controlli erano computazionalmente onerosi.

Componenti interessati: Engine Framework

È stato risolto un problema relativo al recupero di oggetti Singleton via Plugin (mediante l’invocazione context.getEntitySession().get<SingletonName>()), per cui veniva sollevata un’eccezione qualora fossero presenti più classi Singleton. Ciò era dovuto al fatto che il framework gestiva internamente gli ID delle istanze Singleton in modo analogo alle altre classi non-Singleton, pur non avendo queste degli ID univoci su tutto il sistema. La logica interna al framework è stata pertanto modificata assegnando identificatori “speciali” alle istanze Singleton e Enum, risolvendo l’eccezione sollevata da get<SingletonName>().

Componenti interessati: SPI Plugin

Per velocizzare le operazioni di abilitazione/disabilitazione di attributi a livello di Application Schema, sono stati introdotti due nuovi comandi nel menu contestuale delle classi (Class menu):

• Enable > all attributes permette di abilitare tutti gli attributi definiti per la classe;
• Disable > all attributes permette di disabilitare tutti gli attributi definiti per la classe.

Componenti interessati: Designer

È stato risolto un problema relativo alla valutazione della funzione date() (la quale effettua il parsing di una stringa rappresentante una data in base a un formato), per cui i valori temporali restituiti erano riferiti al giorno precedente. La causa del problema era dovuta al fatto che la funzione date() utilizzava erroneamente la timezone della Cloudlet, invece della timezone di default di Livebase (GMT).

Componenti interessati: Engine Framework

Nelle query che prevedono il recupero di oggetti part o associati, il framework non prevede di applicare eventuali Class Filter definiti sulla classe target puntata dal ruolo interessato dall’espansione, dal momento che questi filtri sono considerati solo quando la classe è radice della query.

Questo comportamento era rispettato dalle query originate dal Client web o da Plugin, ma non da quelle provenienti da chiamate GraphQL, che a causa di ottimizzazioni previste dal framework applicavano erroneamente i Class Filter delle classi target anche nell’espansione dei ruoli che puntano a esse.

Componenti interessati: Engine Framework (Runtime Query Generator)

Le operazioni di commit sui database delle Cloudlet sono state rese più efficienti con i seguenti interventi:

• ottimizzazione della logica del controllo di esistenza nel database per le operazioni di merge degli oggetti in sessione;
• rimozione di ulteriori controlli di esistenza non necessari all’interno delle operazioni di gestione dei lock sugli oggetti.

Per effetto di questi interventi, i tempi di esecuzione sono stati dimezzati.

Componenti interessati: Engine Framework

È stato risolto un problema relativo alla valutazione delle espressioni math, per cui veniva sollevata un’eccezione a runtime in presenza di variabili riferite a classi Enum o Singleton con valore nullo.

Componenti interessati: Engine Builder

Selezionando la voce Help dal menu contestuale di una Cloudlet, verranno ora mostrate sia la versione Livebase di riferimento sia quella delle API GraphQL, in modo da facilitare lo sviluppo dei plugin compatibili.

Componenti interessati: Dashboard Client, Dashboard Servant

È ora possibile configurare il meccanismo CORS (Cross-Origin Resource Sharing) direttamente dalla Dashboard, senza dover agire sul database.

Per farlo, è necessario accedere al pannello di configurazione della Cloudlet e selezionare la voce Configure... dal suo menu contestuale. Il suddetto pannello presenta una nuova scheda denominata CORS, la quale contiene i controlli per abilitare o disabilitare il meccanismo e specificare gli header forniti dal server durante l’autenticazione del client. È anche presente un link alla documentazione CORS, allo scopo di facilitare le operazioni di configurazione.

Componenti interessati: Dashboard Client, Dashboard Servant

Per semplificare la catalogazione delle versioni dei modelli Livebase, è stata ripensata la denominazione dei relativi file .xml scaricabili dalla Cloudlet, in maniera analoga a quanto è avvenuto per i nomi dei .jar delle SPI nella versione 5.11.2.

• i modelli scaricati dalla libreria hanno come nome di default <ModelName>_<Version>.xml;
• i modelli scaricati dalle Cloudlet e allineati con la versione di libreria hanno come nome di default <ModelName>_<Version>.xml;
• i modelli scaricati dalle Cloudlet e con versione superiore a quella di libreria hanno come nome di default <ModelName>_<Version>_modified.xml;
• i modelli scaricati dalle Cloudlet e senza un corrispettivo in libreria hanno come nome di default <ModelName>.xml.

<Version> indica il numero di versione del modello con i tre numeri separati da underscore invece che dal punto (ad es. 1_0_0 al posto di 1.0.0).

Componenti interessati: Dashboard Client, Dashboard Servant

In precedenza, se un determinato utente possedeva molte Cloudlet, il caricamento della Dashboard successivo all’operazione di login richiedeva tempi elevati; questo accadeva perché ogni singola Cloudlet veniva contattata in modo sincrono attraverso l’Hosting Servant per effettuare controlli di raggiungibilità ed esistenza (accertando che ogni Cloudlet risulti registrata sia presso il Dashboard Servant che presso l’Hosting Servant).

Per risolvere questo problema è stato introdotto un procedimento di preparazione asincrona, per cui viene inizialmente generato un descrittore minimale per ciascuna Cloudlet, mentre le verifiche di raggiungibilità ed esistenza procedono in background.

Componenti interessati: Dashboard Client, Dashboard Servant

È stato risolto un problema in fase di check del database: tentando di mappare i ruoli di una relazione tra una classe Form e una Enum veniva sollevata una NullPointerException. Ciò era dovuto al fatto che la procedura di check è pensata per ignorare il mapping di relazioni in cui almeno uno degli estremi è una classe Form, ma questo non avveniva se l’altro estremo era una classe Enum.

Componenti interessati: Database Checker

Il portale www.fhoster.com è stato dismesso e sostituito con un nuovo portale all’indirizzo www.livebase.com.

La sostituzione ha comportato i seguenti cambiamenti:

• La Dashboard va ora scaricata dal seguente URL: www.livebase.com/download ;
• È stata disabilitata la possibilità per i clienti di creare autonomamente un account master. La creazione dell’account master per i nuovi clienti viene ora effettuata dallo staff Fhoster in back-office;
• La Dashboard è stata estesa con funzionalità che consentono all’account master di modificare le proprietà dell’account e di gestire i sub-account.

È ora possibile effettuare il download dello SPI di un modello direttamente dalla libreria, senza prima doverlo installare in una Cloudlet.

A questo scopo, il menu contestuale richiamabile facendo clic destro su un modello comprende ora la voce Download SPI....

Componenti interessati: Dashboard Client, Dashboard Servant

È stato risolto un problema nel recupero attraverso query GraphQL di attributi di tipo Date e di valori math calcolati a partire da questi. I valori math erano infatti ricalcolati utilizzando la timezone locale del server, anziché la timezone GMT su cui si basa Livebase; per questo motivo venivano generate risposte in cui essi si trovavano un giorno avanti o indietro rispetto al risultato atteso, come in questo esempio in cui math1 è semplicemente un alias di attribute1:

{
  "data": {
    "Class1___getPage": {
      "items": [
        {
          "attribute1": "16-Apr-2021",
          "math1": "15-Apr-2021"
        }
      ]
    }
  }
}

Componenti interessati: API GraphQL, Engine Framework (Runtime Query Generator)

È stato risolto un problema per cui, effettuando query GraphQL che richiedevano informazioni relative a ruoli che puntavano a classi Enum, venivano sollevati degli errori.

Ciò si verificava perché Livebase non prevede costrutti che rappresentano specificamente dei ruoli (class role) nel caso di classi part, Form e Enum. Il Runtime Query Generator gestiva correttamente questa particolarità solo per i primi due casi, per cui è stato necessario apportarvi delle modifiche per contemplare anche la casistica delle classi Enum.

Componenti interessati: API GraphQL, Engine Framework (Runtime Query Generator)

In previsione della dismissione del portale Fhoster, sono state introdotte le seguenti funzionalità all’interno della Dashboard:

• gestione dei subaccount: cliccando sul nome del proprio account, in alto a destra, è ora presente la voce Subaccounts..., la quale apre un pannello che elenca tutti i subaccount associati, consentendone inoltre la creazione ed eliminazione;
• cambio password: sempre facendo clic sul nome del proprio account, il menu contestuale presenta ora la voce Change Password..., la quale apre un pannello che richiede la conferma del processo con l’immissione della vecchia password e di quella nuova;
• recupero password: nella finestra di login è ora presente il link Forgot?. Cliccando su di esso viene richiesto il proprio nome utente o la propria e-mail. Una volta confermati questi dati, si riceve un codice da immettere nella finestra successiva per confermare il reset della propria password.

Componenti interessati: Dashboard Client, Dashboard Servant

È stata aggiunta l’indicizzazione sulla data di archiviazione delle versioni dei modelli, in modo da migliorare le prestazioni di accesso.

Componenti interessati: Dashboard Database

È stato risolto un problema per cui, in fase di salvataggio di un modello che presenta Low issue relative a elementi mancanti, gli LCP non venivano correttamente aggiornati.

Quando un modello viene salvato con elementi mancanti, Livebase avvia una procedura che risolve le issue aggiungendoli automaticamente. Precedentemente, le operazioni seguivano un ordine di esecuzione che portava alla sovrascrittura dell’incremento di LCP relativo ai nuovi elementi. La soluzione è quindi consistita nel modificare la procedura inserendo un’operazione che forza il ricalcolo degli LCP, facendola terminare con l’aggiornamento al valore corretto.

Componenti interessati: Designer

Sono stati aggiunti i servizi di tipo generico anche per le classi Form, con lo scopo di offrire strutture dati comuni e di facile utilizzo.

In particolare, sono stati aggiunti solo i servizi di tipo preview, in quanto non è possibile persistere o modificare oggetti appartenenti a classi Form (operazione svolta da save), e non risulta significativo controllare la correttezza di queste operazioni (operazione svolta da validate). Il parametro accettato è la struttura <FormClassName>Draft che è già utilizzata nei servizi che permettono l’invocazione di FormActionHandler.

Inoltre, non essendo possibile persistere le classi Form, non è necessario consentire preview di tipo update, che nel caso di servizi generici si ottengono valorizzando il campo _id nella relativa mutation: se si effettua una chiamata con tale campo valorizzato viene restituito un errore di tipo MALFORMED_REQUEST.

Componenti interessati: API GraphQL

Lavorando sulle operazioni di merge a carico del Runtime Query Generator, ed effettuando ulteriori interventi sulla modellazione, è stato possibile ridurre i tempi di esecuzione di chiamate GraphQL molto complesse da 8 secondi fino a circa 2 secondi.

Componenti interessati: API GraphQL, Engine Framework (Runtime Query Generator)

Creando oggetti part attraverso l’esecuzione di un ListActionHandler, per poi entrare in modifica sui suddetti senza persistere i cambiamenti, si notava la sparizione del part appena creato. Ciò era dovuto al fatto che l’esecuzione del ListActionHandler non rispettava le condizioni necessarie ad attivare una logica di persistenza in memoria per gli eventuali oggetti creati.

Componenti interessati: Engine Framework

È stato aggiunto un apposito pannello nella schermata di configurazione della Cloudlet, che permette di abilitare e configurare il meccanismo SSO (Single Sign-On), senza dover agire manualmente sul database.

Il pannello è raggiungibile dal Cloudlet menu (), selezionando l’opzione Configure... e accedendo alla scheda SSO della finestra di dialogo mostrata.

Il contenuto prevede una casella di controllo che specifica se attivare o meno il meccanismo, e un campo testuale per il JSON che servirà da configurazione.

Componenti interessati: Dashboard Client, Dashboard Servant

Nel caso in cui venga effettuata la start di una Cloudlet e che sia necessario generare un numero di LCP superiore al quantitativo residuo, viene ora mostrato un messaggio di errore che indica di quanto è stato superato il limite consentito. Questo permetterà all’utente di rivedere la complessità del modello che intende generare per tentare di riportare il conteggio degli LCP necessari sotto il limite.

Componenti interessati: Dashboard Client, Dashboard Servant

È stato risolto un problema che portava al sollevamento di un errore 403 (Forbidden), a seguito della scadenza di una sessione nella Dashboard. La causa è stata individuata nella perdita del comportamento di redirect alla schermata di login, prima gestito da un CAS (Central Authentication Service): l’errore è scomparso dopo il recupero e il reinserimento di tale comportamento.

Componenti interessati: Dashboard Client, Dashboard Servant

In presenza di problemi di sincronizzazione tra Dashboard Database e Hosting Servant, in particolare se il primo segnalava la presenza di una Cloudlet non registrata nel secondo, il login dell’utente veniva completamente negato e veniva sollevato un errore. Questo problema è stato risolto eliminando l’errore e marcando le Cloudlet assenti nell’Hosting Servant come irraggiungibili (unreachable).

Componenti interessati: Dashboard Database, Hosting Servant

Le funzionalità di visualizzazione della subscription e modifica del limite mensile di LCP sono state migrate dal vecchio portale Livebase alla Dashboard, in previsione della dismissione del primo.

Queste funzionalità sono ora accessibili facendo clic sul proprio nome utente in alto a destra, nella schermata principale della Dashboard.

Componenti interessati: Dashboard Client, Dashboard Servant

Il CAS (Central Authentication Service), ovvero il componente che permetteva di realizzare il Single Sign-On tra il portale Livebase e la Dashboard, è stato rimosso dalle procedure di login su quest’ultima, in quanto il portale è in dismissione.

Componenti interessati: Dashboard Client, Dashboard Servant

Nel caso in cui il modellatore installi su una Cloudlet un modello, quando il relativo database fa riferimento a una versione del medesimo in stato MODIFIED, viene ora mostrato un messaggio che avvisa di una possibile perdita dei dati memorizzati.

Ciò è fatto per notificare l’utente di un problema a carico del meccanismo di allineamento, per cui la rinominazione di una classe viene talvolta effettuata cancellando e ricreando la relativa tabella.

Componenti interessati: Dashboard Client, Dashboard Servant

La funzionalità Find unused model elements, che permette di individuare e rimuovere tutti gli elementi del modello non utilizzati, è stata migliorata come segue:

• è stata aggiunta la possibilità di eliminare solo alcuni degli elementi individuati, selezionandoli e facendo clic sul pulsante Delete selected;
• per modelli di grandi dimensioni, viene mostrata una barra di avanzamento per il processo di eliminazione, che fornisce anche la possibilità di annullare l’operazione in ogni momento.

Componenti interessati: Designer

Risolto un problema per cui, eliminando un modello appena creato, veniva erroneamente mostrato un messaggio che indicava l’inesistenza di tale modello; l’errore scompariva dopo aver chiuso la finestra di dialogo.

La causa è stata individuata nelle politiche di lock e unlock: ogni operazione effettuata su un modello acquisiva inizialmente un lock sull’oggetto coinvolto per poi rilasciarlo una volta conclusa. Nel caso di un’eliminazione, l’oggetto coinvolto non è più presente al termine dell’operazione; ciò rendeva impossibile rilasciare il lock e causava l’errore sopra citato.

Componenti interessati: Dashboard

Risolto un problema per cui, archiviando un modello il cui engine è in stato MODIFIED, veniva unicamente aggiornata la versione di quella particolare replica; eventuali altre repliche installate su Cloudlet differenti continuavano a mostrare la versione precedente o la dicitura MODIFIED.

Componenti interessati: Dashboard Client, Dashboard Servant

Risolto un errore concettuale che determinava l’aumento del major number della versione di un modello anche se erano aggiunte relazioni tra classi Form.

Il major number viene aggiornato a seguito di modifiche alla struttura del database della Cloudlet. Aggiungere relazioni tra classi Form non richiede di modificare questa struttura, perciò è più appropriato incrementare il minor number.

Questa correzione determina anche un aumento delle performance di build, in quanto l’incremento del major number attiva una serie di computazioni di aggiornamento e di verifica della struttura che possono risultare superflue, nel caso in cui questa non abbia subito modifiche significative.

Componenti interessati: Dashboard Client, DashboardServant

Per prevenire bug di difficile soluzione causati dal branching delle versioni dei modelli, è stato deciso di impedire, per modelli archiviati, di impostare una delle loro versioni come corrente. Di conseguenza, non è più presente il pulsante Set as current nel pannello di gestione delle versioni (richiamabile selezionando l’opzione Versions... nel menu contestuale del modello archiviato); inoltre, per tutti i modelli già presenti in produzione è stata settata l’ultima versione archiviata.

Componenti interessati: Dashboard Client, Dashboard Servant

Nel caso in cui un FormActionHandler sia invocato tramite le API GraphQL, e che a esso venga passata un’istanza di classe Form come insieme di parametri, il framework esegue una validazione contestuale di tali parametri in funzione dei vincoli dichiarati sul modello.

Questo intervento semplifica la scrittura del codice del Plugin, in quanto non richiede più allo sviluppatore di gestire manualmente la validazione dell’input.

Componenti interessati: Engine Framework

Risolto un problema relativo all’uso di API GraphQL personalizzate (definite come CloudletRestletPlugin), che venivano oscurate da quelle di sistema offerte dalla Cloudlet.

Ciò era dovuto alle modalità con cui venivano esposte le GraphQL di sistema e quelle personalizzate: era generata un’unica risorsa Restlet che portava le API a condividere la porzione di URL auth/api/graphql, determinando una collisione risolta con una strategia first match. La soluzione è consistita nell’adozione di una strategia best match e nella generazione di una risorsa per ogni applicazione della Cloudlet.

Componenti interessati: Engine Framework, API GraphQL

È stato risolto un problema che determinava la non valorizzazione dei ruoli (sia delle associazioni sia delle composizioni) delle classi Form, quando queste erano usate come parametri di input per i servizi GraphQL che permettono di invocare i FormActionHandler.

Ciò era dovuto alla routine di pre-processamento dei parametri, che non costruiva ricorsivamente le catene di oggetti associati se il servizio GraphQL riceveva una classe Form.

Componenti interessati: API GraphQL

Il pannello informativo della Cloudlet API & Public URLs è stato corretto perché rispetti il case (maiuscolo o minuscolo) dei nomi delle viste applicative di riferimento per ciascun endpoint GraphQL. Ad esempio, se il nome di una vista è Test, l’endpoint GraphQL corretto è <CloudletUrl>/auth/api/graphql/Test.

Componenti interessati: Dashboard Servant

Nello schema GraphQL generato, è stato rimosso il vincolo required (simbolo !) prima imposto sul parametro data nei servizi per l’invocazione dei FormActionHandler (maggiori informazioni disponibili qui). Il parametro in questione era in precedenza obbligatorio pur essendo di tipo draft e quindi con tutti i campi opzionali, il che consentiva di passare un oggetto vuoto (data: {}), ma essendo il campo obbligatorio non era possibile non passarlo completamente. Avendo rimosso il vincolo required, ora è invece possibile non passare affatto il campo, con il risultato analogo di passare un data vuoto.

Componenti interessati: API GraphQL

Per semplificare la catalogazione delle versioni delle SPI in rapporto all’evoluzione del modello di riferimento, sono state ripensate le politiche di naming per il file .jar contenente le interfacce SPI di una Cloudlet, scaricabile dal pannello dei Plugin.

Il nome del file .jar segue ora le seguenti regole:

• se il modello installato sulla Cloudlet è archiviato in libreria con la stessa versione, il nome avrà la forma <ModelName>_<VersionNumber>_spi.jar;
• se il modello è archiviato in libreria, ma è installata una versione superiore, il nome avrà la forma <ModelName>_<VersionNumber>_modified_spi.jar;
• se il modello non è archiviato in libreria, il nome avrà la forma <ModelName>_<SaveTimestamp>_spi.jar.

<VersionNumber> è il numero di versione del modello con i tre numeri separati da underscore invece che dal punto (ad es. 1_0_0 al posto di 1.0.0). <SaveTimestamp> rappresenta la data e l’ora (timestamp) dell’ultimo salvataggio del modello; i caratteri di separazione sono ancora sostituiti da underscore (es. per il timestamp 12/10/2020 13:14 si avrebbe 12_10_2020_13_14).

Componenti interessati: Dashboard Client, Dashboard Servant

Eseguendo una chiamata GraphQL che coinvolge associazioni con ruoli aventi lo stesso nome, specialmente tra classi regolari e classi Form, si verificava un problema per cui venivano generate query SQL su campi non voluti, portando alla restituzione di risultati inattesi.

Ciò era dovuto al fatto che le operazioni di disambiguazione dei ruoli ignoravano il nome della classe a cui il ruolo si riferiva, ovvero la classe presso cui è presente il “pallino” del ruolo nel Designer. I controlli sono quindi stati irrobustiti al riguardo considerando anche i ruoli cosiddetti “non validi”, ovvero quelli definiti dal sistema ma non editabili dall’utente per la mancanza del relativo pallino, come ad esempio quelli che puntano a classi Form. Per questi ruoli è stata inoltre definita la convenzione di aggiungere un doppio underscore all’inizio del loro nome, per evitare di introdurre ambiguità indesiderate con i ruoli definiti dall’utente.

Componenti interessati: Model

È stato individuato un problema per cui, se la cardinalità di un ruolo uscente da una classe sottoposta a versioning era modificata da 0N a 1, il Designer segnalava una low issue proponendo la risoluzione automatica, ma a seguito della conferma dell’operazione veniva sollevato un errore generico.

Ciò era dovuto alle operazioni eseguite sul database a causa della restrizione della cardinalità: la generazione di una colonna di associazione NOT NULL rendeva inconsistente lo storico delle versioni della classe in questione.

Si è pertanto deciso di rivedere il meccanismo delle issue relative al versionamento, nel caso particolare in cui una classe versionata e una non versionata sono unite da una relazione bidirezionale non vincolata (con cardinalità 0N per entrambi i ruoli):

• restringere a 1 il ruolo uscente dalla classe versionata solleva una high issue, per il motivo di cui sopra;
• restringere a 01 il ruolo uscente è permesso, in quanto la colonna di associazione sarebbe nullabile e non introdurrebbe rischi di inconsistenza nello storico;
• aumentare la cardinalità minima del ruolo uscente è permesso, in quanto si avrebbe una tabella di relazione che attualmente non si sottopone al versioning;
• restringere a 01 il ruolo entrante nella classe versionata è permesso, almeno finché anche l’altra classe non viene versionata.

Componenti interessati: Database Checker

È stata introdotta la possibilità di definire particolari tabelle nel database delle Cloudlet, il cui unico scopo è fornire supporto all’operatività dei plugin sviluppati dai clienti Livebase. Queste tabelle, alle quali è stato riservato il prefisso @ext@, non sono supportate dalle operazioni della dashboard. In generale, saranno ignorate da qualsiasi aspetto di Livebase che non sia il codice prodotto dai clienti.

Le tabelle @ext@ non possono inoltre relazionarsi con tabelle del modello (se non con relazioni lasche), per non interferire con l’operatività della cloudlet a livello delle operazioni CRUD.

Componenti interessati: Cloudlet Database

È stata introdotta l’interfaccia SpiCloudletSMSSender, la quale permette di realizzare servizi di notifica via SMS attraverso i plugin Livebase.

Il framework non fornisce un’implementazione per l’interfaccia, per cui lo sviluppatore che intende utilizzarla deve realizzare una classe implementativa e decorarla con l’annotazione @CloudletSMSSender. Questo permetterà al framework di effettuare il binding dell’implementazione in maniera dinamica, e consentirà l’iniezione di SpiCloudletSMSSender in tutti i plugin che la richiedono.

public interface SpiCloudletSMSSender {
  void sendSMS(SMSMessage message);
}

Componenti interessati: SPI Plugin

Le API per lo sviluppo di plugin comprendono ora l’interfaccia SpiCloudletPluginActivator, la quale permette di aggiungere logica personalizzata in concomitanza con le operazioni di start e stop dell’intero .jar del plugin.

public interface SpiCloudletPluginActivator {
  void start();
  void stop();
}

Componenti interessati: SPI Plugin

Usando i plugin Restlet (CloudletRestletPlugin), è ora possibile esporre risorse REST personalizzate di tipo pubblico, ovvero che non richiedono autenticazione.

L’esposizione delle risorse pubbliche si ottiene agendo sul valore di ritorno di getType(), metodo astratto della classe RestletServletResource da cui derivano tutte le classi dei plugin Restlet:

public RestletServerResourceType getType()

La enum RestletServletResourceType ammette a questo proposito i due nuovi valori PUBLIC_EXT e PUBLIC_GRAPHQL.

Le risorse create senza autenticazione saranno rese disponibili su URL del tipo <CloudletUrl>/public/api/ext/<ResourceUrl>, a differenza delle risorse autenticate che invece sono disponibili su URL come <CloudletUrl>/auth/api/ext/<ResourceUrl>.

Componenti interessati: Cloudlet SPI, Engine Framework, Engine Builder

Precedentemente, rinominare una classe o un membro con versionamento forzava il database a ricreare le relative strutture (i.e. tabelle e colonne), facendo perdere lo storico delle versioni. Questa logica è stata migliorata per fornire un supporto completo alla rinominazione evitando la perdita di dati.

Componenti interessati: Database Checker

È stato risolto un problema che portava a un fallimento dell’operazione di generazione delle Cloudlet, qualora nel modello fosse presente una classe denominata Report. La presenza di questa classe, infatti, faceva sì che l’Engine Builder costruisse internamente due interfacce con lo stesso nome, sollevando un errore di compilazione.

Componenti interessati: Engine Builder

È stato risolto un problema per cui, utilizzando i servizi GraphQL generici esposti per le varie classi (query di tipo preview e mutation di tipo save), non potevano essere applicate modifiche ai part con cardinalità pari a 1. Veniva infatti creato un nuovo part che causava violazioni di cardinalità.

Componenti interessati: API GraphQL

L’operazione di Start delle Cloudlet prevede un’ottimizzazione che, in fase di deploy di un engine, permette di riciclare l’engine già costruito per la nuova Cloudlet, anche se questa è ospitata su un diverso Hosting Server. In quest’eventualità, infatti, si verifica un handover diretto dell’engine tra un server e l’altro.

Precedentemente, se i due server non riuscivano a comunicare, veniva sollevato un errore, ma questo comportamento è stato risolto grazie al Dashboard Servant, che può ora fungere da ponte tra i due server per permettere comunque il completamento dell’handover.

Componenti interessati: Dashboard Servant

Sono state apportate delle modifiche per mostrare sempre il contatore degli LCP utilizzati nella parte inferiore della scheda Cloudlets, anche quando il quantitativo (specialmente a inizio mese) è pari a 0.

Componenti interessati: Dashboard

Le Cloudlet non consentono più di effettuare download e upload del proprio database attraverso dump in formato .mdb (Microsoft Access).

Componenti interessati: Dashboard, Dashboard Servant

Qualora una Cloudlet abbia un engine (anche MODIFIED) costruito su un modello la cui versione è più vecchia di quella nella libreria, non è più possibile effettuarne l’archiviazione.

Come esempio, consideriamo una Cloudlet con un engine MODIFIED il cui modello è alla versione 2.0.0. Se in libreria lo stesso engine è stato aggiornato ad una versione superiore, come 4.0.0, trascinare il modello dalla Cloudlet alla libreria per effettuarne un’archiviazione mostrerà ora un errore, invece di generare una nuova versione e settarla come attuale.

Componenti interessati: Dashboard, DashboardServant

Nel Designer Livebase, sono stati effettuati i seguenti interventi a carico della finestra di dialogo relativa all’operazione di abilitazione del system versioning:

• è stata temporaneamente sospesa la possibilità di modificare manualmente i membri da sottoporre a versioning, attraverso la rimozione delle checkbox relative accanto a ciascuno di essi. La finestra di dialogo assume quindi una funzione di recap dei membri storicizzati, il cui nome è mostrato in grassetto;
• se non è possibile sottoporre a versioning un determinato ruolo di relazione, è presente una descrizione del motivo, corredata di un link se è possibile farlo abilitando il versioning nella classe opposta;
• nel caso di relazioni riflessive è mostrato solo il ruolo sorgente.

Componenti interessati: Designer

È stata rimossa la possibilità di impostare valori di default per gli attributi di piattaforma (Platform attribute).

Componenti interessati: Model, Designer

Sono stati aggiunti due endpoint amministrativi alle Cloudlet generate, i cui URL sono visionabili aprendo la schermata Administration Services nel client GWT. Il primo endpoint prevede l’accesso al registro dei lock attivi sugli oggetti; il secondo esegue l’interrogazione di un servizio di health check.

Componenti interessati: Cloudlet Framework

È stato risolto un problema per cui, usando il client GWT per modificare gli User di una certa Cloudlet, compariva il seguente valore in corrispondenza del campo Team: {"value":"admin","computedValue":""}. La causa è stata individuata nelle tracce delle vecchie API REST che sono in corso di rimozione.

Componenti interessati: Engine Framework (GUI)

Sono stati risolti diversi problemi legati all’utilizzo di filtri e cursori, relativamente a campi temporali (Date e Datetime) formattati con un pattern comprendente il nome del mese (MMM o MMMM in notazione Java):

• una query comprendente solo il filtro, con l’effetto di memorizzare un cursore in un’apposita variabile, restituiva una risposta con totalCount inconsistente rispetto alla dimensione del risultato;
• riutilizzare un cursore restituito in una query precedente produceva risposte con campo items vuoto.

Questi problemi erano dovuti alla mancanza di supporto per la localizzazione in italiano da parte delle funzioni adoperate per formattare i campi temporali; esse accettavano infatti la sola localizzazione in inglese e sollevavano delle eccezioni non visibili, che producevano risultati incongruenti.

Componenti interessati: API GraphQL

È stato risolto il seguente problema: richiedendo tramite una query getPage gli attributi di un particolare oggetto e quelli degli oggetti associati, se questi ultimi comprendevano attributi di tipo file, veniva restituita una risposta comprendente un valore di totalCount pari a 0.

Il problema era dovuto ad un errore in una logica particolare, che effettua una riscrittura della risposta GraphQL in presenza di attributi non mappati direttamente sul database, quali l’attributo file. Questa logica ignorava l’attributo speciale totalCount, che veniva così assegnato a null e poi tradotto in un valore 0 nei successivi processamenti.

Componenti interessati: API GraphQL

Livebase effettua ora controlli sui dati di abbonamento (ovvero le subscription) per ciascun utente. In particolare, se l’utente ha sottoscritto un abbonamento mensile, per cui è previsto un limite di LCP (Livebase Complexity Points) generabile attraverso build per ogni periodo di fatturazione, egli non sarà più in grado di avviare nessuna Cloudlet che superi tale limite con la relativa build propedeutica.

La dashboard mostra inoltre all’utente il quantitativo di LCP utilizzato e quello massimo per il mese, attraverso un opportuno indicatore nella parte inferiore della scheda Cloudlets.

Infine, per evitare risultati inconsistenti nel controllo dei limiti di LCP a causa di start concorrenti, è stato aggiunto un controllo che impedisce l’avvio contemporaneo di più di una Cloudlet se l’utente ha un limite mensile.

Componenti interessati: Dashboard, Dashboard Servant, Dashboard Database

È stato introdotto Hazelcast Client all’interno dell’Engine Framework, allo scopo di gestire il controllo di concorrenza in ambiente distribuito. Può essere abilitato con un’opportuna configurazione per tutte le cloudlet ridondate e distribuite.

Componenti interessati: Engine Framework

Per le operazioni di download, backup, clone e drag & drop relative ai database è stato aggiunto un meccanismo di notifica che, nel caso in cui sia abilitato il system versioning su almeno una classe del modello, avverte l’utente che solo l’ultima versione di tutti gli oggetti sarà esportata o replicata.

Componenti interessati: Dashboard Client, Dashboard Servant

È stato risolto un problema che impediva il login nella Dashboard, a causa di inesattezze durante il processo di serializzazione delle eccezioni.

Componenti interessati: Dashboard Servant, Hosting Servant

Sono stati risolti alcuni problemi nell’algoritmo per il calcolo degli LCP nei seguenti scenari:

• Trasformazione di una composizione: se una composizione viene trasformata in un’associazione filtrata (facente uso di un selection path), si verifica un’eccezione in fase di comparazione dei filtri tra le versioni, in quanto questi non sono supportati dalle composizioni;
• Modifica del tipo di attributo: se un attributo viene rimosso e poi creato nuovamente, ma con un tipo che possiede un dominio diverso (come nel caso del passaggio da Integer a Date), si verifica un’eccezione dovuta all’impossibilità di comparare i domini degli attributi tra le versioni.

Componenti interessati: Designer

È stata aggiunta una funzionalità che permette di effettuare il rebuild delle sole API GraphQL. Precedentemente era necessario eseguire il rebuild di tutta la Cloudlet.

La funzionalità è presente come opzione nel menu a tendina (pulsante nell’angolo inferiore destro del riquadro della Cloudlet):

Componenti interessati: Dashboard Client, Dashboard Servant

È stato risolto un problema per cui i parametri relativi alle classi Profile, Singleton e Enum non venivano correttamente popolati quando venivano effettuate query su ruoli (associati e associabili). Per effetto di questo problema venivano restituiti risultati differenti a seguito del passaggio delle options nelle query di paginazione riferite ai ruoli.

Componenti interessati: Engine Framework (Runtime Query Generator)

È stato risolto un problema per cui il parametro __System.datetime, se usato più volte all’interno della stessa query, causava degli errori inaspettati.

Ciò era dovuto a un controllo di consistenza all’interno del RuntimeQueryGenerator, che verifica che uno stesso token non abbia più di un valore assegnato nella fase di parsing e costruzione della relativa query SQL. Poiché __System.datetime rappresenta il timestamp di sistema, che per natura assume valori diversi continuamente, nel momento in cui esso veniva usato come token si verificavano dei falsi positivi.
E’ stato dunque modificato il comportamento di questo controllo in modo che non sollevi eccezioni se __System.datetime è usato più volte.

Componenti interessati: Engine Framework (Runtime Query Generator)

È stato risolto un problema per cui un FormActionHandler non rilasciava i lock acquisiti sugli oggetti influenzati se la sua esecuzione falliva. Questo causava conseguenti problemi di concorrenza che impedivano l’accesso a quegli oggetti da parte di altre sessioni.

Componenti interessati: Engine Framework, Cloudlet

È stato modificato il comportamento dell’opzione Rebuild & start presente nel menu contestuale della Cloudlet: se l’engine necessita di un upgrade, non è possibile rigenerare e avviare la Cloudlet.

Componenti interessati: Dashboard Client, Dashboard Servant

È stato aggiunto uno switch che permette di attivare o disattivare le GraphQL in una Cloudlet. Precedentemente questo era possibile solo tramite il database.

È possibile trovare questo switch nel pannello API della Cloudlet (fare clic sul pulsante a forma di spina elettrica, nell’angolo superiore destro del riquadro della Cloudlet), come mostrato nella seguente figura:

Componenti interessati: Dashboard Client, Dashboard Servant

Precedentemente, un fallimento del sistema di calcolo degli LCP causava anche un fallimento dell’operazione di avvio della relativa Cloudlet.

Considerando che il calcolo degli LCP è un’operazione di fatturazione, non strettamente legata all’operatività di Livebase, si è deciso di consentire comunque l’avvio della Cloudlet in presenza di questo tipo di errori, effettuando il log dell’operazione all’interno del Dashboard Database in modo che possano essere presi in carico dal team di sviluppo.

Componenti interessati: Dashboard Client, Dashboard Servant

A causa di alcune ambiguità nell’importazione di attributi che rappresentano informazioni temporali, in particolare date e datetime, è stato temporaneamente rimosso il supporto al pattern mm/dd/yyyy usato nei paesi anglofoni.

Componenti interessati: Excel Importer

È stata rimossa la possibilità di effettuare il drag & drop di un modello in libreria all’interno di una Cloudlet running, considerata ridondante e soggetta a errori.

Componenti interessati: Dashboard Client, Dashboard Servant

Le classi Form, non avendo un class role, hanno uno stato di abilitazione che dipende unicamente dal ruolo attraverso cui sono puntate. È stato risolto un problema per cui, se tali classi costituivano i part di una composizione, risultavano disabilitate anche se il relativo ruolo era abilitato.

Componenti interessati: Designer

È stato risolto un problema che provocava il lancio di un’eccezione, qualora veniva salvato un modello avente nella propria rappresentazione caratteri non compresi nel charset latin1. La soluzione è consistita nel predisporre il sistema per adottare in ogni circostanza il charset utf8.

Componenti interessati: Dashboard Servant

Sono stati risolti dei problemi dovuti al meccanismo CORS (Cross-Origin Resource Sharing), nel caso in cui per una certa cloudlet sia abilitato l’SSO (Single Sign-On) attraverso Keycloak. Si ha infatti che sia Livebase sia Keycloak prevedono un filtro CORS, i quali attivandosi contemporaneamente a valle di una richiesta facevano sì che il server fornisse risposte di preflight inconsistenti, generando dei falsi negativi nell’autorizzazione di un ipotetico client. La soluzione è consistita nel modificare questa logica, impedendo l’attivazione del filtro CORS di Livebase qualora l’SSO sia abilitato per una certa Cloudlet.

Componenti interessati: Cloudlet Framework

È stato risolto un problema dovuto a imprecisioni nella conversione dei parametri limit e next, utilizzati per la paginazione in GraphQL (per mezzo di una funzionalità chiamata window functions), nei loro equivalenti SQL limit e offset, che produceva risultati inconsistenti.

Componenti interessati: Engine Framework (Runtime Query Generator)

La label di informazione sugli LCP da addebitare per il ciclo di fatturazione attuale è stata corretta: è stato sostituito il termine generated con charged.

Componenti interessati: Dashboard Client

Sono stati eseguiti i seguenti interventi sul sistema di fatturazione degli LCP e sul relativo file excel:

• è stato migliorato l’aspetto grafico del file, attraverso un refactor degli stili;
• per ogni modello che ha subito delle generazioni, è stato aggiunto un foglio che riporta tutti gli incrementi di LCP. Gli incrementi sono ordinati cronologicamente e per classe, intendendo per “ordine cronologico” dalla generazione del modello più vecchia a quella più recente;
• il formato delle descrizioni degli incrementi ha ora una struttura maggiormente discorsiva, rispetto a quello utilizzato nel Dashboard Client;
• per ovviare al fatto che il nome di un foglio non può superare i 31 caratteri, ad ogni modello è assegnato un progressivo nel foglio di Overview (es. M1, M2, ecc.). I fogli degli incrementi sono nominati di conseguenza;
• considerando che la prima generazione ha incremento pari al peso, sono in questo caso elencati tutti gli elementi del modello fino ai 100 LCP.

Componenti interessati: Dashboard Servant

La tabella model_change conteneva svariati record duplicati, identificati come il residuo del problema risolto nel precedente rilascio, relativo alla mancata cancellazione dei ModelChanges dopo la sostituzione dell’engine. I duplicati sono stati rimossi, ed è stato aggiunto un vincolo unique per scongiurare il verificarsi di un analogo problema nel futuro.

Componenti interessati: Dashboard Servant

Nella versione 5.5.3 sono stati introdotti gli LCP (Livebase Complexity Points) come punteggio per rappresentare la complessità dei modelli. Il punteggio del modello corrente è mostrato in basso a sinistra.

Sono state apportate diverse migliorie alla finestra di dettaglio degli LCP:

• modificato il titolo del pulsante da Details a Details...;
• modificato il titolo della finestra in LCP count details;
• rimosso il separatore verticale vicino al pulsante;
• il selettore per la modalità di raggruppamento del rapporto (schema o classi) è stato spostato accanto al pulsante Export as XLSX nell’angolo inferiore destro;
• le due voci del suddetto selettore: ClassBased e SchemaBased, sono state rispettivamente rinominate in Group by class e Group by schema.

Componenti interessati: Designer

Da febbraio 2021 sarà rimosso dalla piattaforma il supporto al codice deprecato presente nello SPI. Nella documentazione javadoc generata per lo SPI sono sempre presenti i riferimenti al codice che va utilizzato al posto di quello deprecato; ad esempio, le strutture Entity prendono il posto dei Bean e gli Stub sostituiscono i Mock.

Gli sviluppatori Livebase registrati hanno ricevuto una mail con allegata la procedura per l’aggiornamento dei plugin, ove necessario; tale procedura graduale è concepita per abbattere la possibilità di introdurre problematiche nelle applicazioni critiche.

Gli aggiornamenti non dovrebbero comportare più di qualche ora per plugin, che potranno essere pianificate con calma fino alla fine di gennaio, data oltre la quale non supporteremo più i servizi deprecati.

Componenti interessati: Engine Framework (SPI)

Le classi stub incluse nello SPI (utili per il testing del codice dei Plugin) sono state arricchite con nuovi servizi che permettono di impostare il valore dei ruoli di tipo part; questi consentono di pre-popolare i ruoli delle classi whole, assegnando ID specifici agli oggetti part.

Componenti interessati: Engine Framework (SPI)

Negli scenari in cui il runtime Karaf (che ospita l’applicazione generata) e il DBMS (che ospita il database della Cloudlet) risiedono su server diversi, è possibile che la mancata sincronizzazione tra gli orologi dei due server introduca errori di runtime.

ad esempio, eseguendo più volte la stessa richiesta GraphQL di tipo Update, a distanza di poco tempo l’una dall’altra, il server sollevava il seguente errore di concorrenza:

Cannot update object <ObjectID> of <ClassName> because it was updated inside another session

Tutti i servizi relativi al recupero del current timestamp sono stati irrobustiti per evitare scenari d’errore come quello di sopra.

Componenti interessati: Engine Framework

Le classi Singleton, introdotte nella versione 5.8, consentono di definire valori globali configurabili, utilizzabili dalle altre classi nelle espressioni math, WHERE e filtri senza doversi associare alla classe stessa. Un Singleton può avere relazioni verso altre classi e può quindi definire attributi di tipo query verso queste classi. Una classe <ClassName> può quindi definire un’espressione math che referenzia uno o più attributi query definiti sul Singleton. La classe contenente questa math può essere inoltre target di relazioni a molti; in GraphQL, il ruolo a molti corrispondente ritorna un risultato paginato <ClassName>Page, personalizzabile tramite l’input <ClassName>PageOptions> (e relativi sotto-campi, tra cui <ClassName>Filter).

Nello scenario di sopra, tuttavia, il server GraphQL non consentiva di usare un qualsiasi filtro, tra quelli basati sul suddetto attributo math, per filtrare il risultato paginato (ad esempio mathAttribute___eq: true). Il server restituiva infatti il campo errors contenente una Issue di tipo SERVER_ERROR.

L’errore è stato ricondotto a una NullPointerException del RuntimeQueryGenerator nella risoluzione delle variabili nelle espressioni math; contestualmente alla risoluzione, sono stati irrobustiti i controlli sul passaggio dei parametri nelle espressioni math.

Componenti interessati: Engine Framework (RuntimeQueryGenerator), API GraphQL

Risolta un’eccezione nel server GraphQL per cui non era possibile inviare richieste contenenti <ClassName>PageOptions in cui si richiedeva il campo filters, ma senza specificare alcun valore (come consentito dallo schema, dato che l’input <ClassName>Filter non ha campi obbligatori).

Il server ora effettua correttamente il parse e risolve richieste di questo tipo:

query {
  Class1___getPage(options: {filter: {}})
}

Componenti interessati: API GraphQL

Risolto un problema per cui le informazioni di insight (richiedibili con l’argomento opzionale insight disponibile per tutti i servizi generati) venivano sovrascritte nella risposta GraphQL in caso di query annidate.

Si verificavano così dei casi in cui venivano mostrate le insight solo per la query alla radice della richiesta, oppure non venivano mostrate affatto se l’argomento non era specificato nelle sotto-query. Il problema è stato risolto facendo in modo che l’argomento insight agisca su tutto il sotto-albero della query; ovvero, se impostato alla radice sarà attivo per tutta la query.

Componenti interessati: API GraphQL

Nelle espressioni definite su una classe è possibile far riferimento ad altri attributi della stessa classe in due modi:

• con la forma estesa: ClassName.attributeName;
• con la forma abbreviata: attributeName.

È stato risolto un problema per cui riferimenti scritti nella forma estesa non venivano risolti correttamente dal RuntimeQueryGenerator.

Componenti interessati: Engine Framework (RuntimeQueryGenerator)

È stato risolto un problema di conversione di tipi per cui, dopo l’assegnazione di valori oltre il range del tipo Integer per gli attributi __id a seguito di un’importazione, veniva sollevata un’eccezione nel momento in cui essi erano richiesti tramite query GraphQL, anche se presenti in espressioni di attributi math. Il problema era legato alla sostituzione dell’attributo __id con _id in base alle convenzioni di GraphQL, che invalidava la logica di conversione tra Integer e BigInteger (tipo interno del database per gli ID dei record persistiti).

Un problema simile è stato riscontrato nella restituzione del seguente errore nella risposta GraphQL:

Can't serialize value (<GraphQLPath>/_id) : Expected type 'ID' but was 'BigInteger'.

dove <GraphQLPath> è il percorso dell’endpoint GraphQL che è stato interrogato. In questo caso, l’errore dipendeva dall’uso di una versione precedente del runtime GraphQL, che non riconosce BigInteger come tipo compatibile per rappresentare un ID. È stato dunque richiesto un aggiornamento delle dipendenze e dei file di configurazione.

Componenti interessati: Engine Framework (QueryGenerator, RuntimeQueryGenerator), API GraphQL

In fondo alla scheda Cloudlets (accanto al bottone New cloudlet) è stato aggiunto il riepilogo totale degli LCP generati nel mese corrente (TOT LCP generated this month); questo conteggio è relativo agli LCP di tutti i modelli dell’account che sono stati impiegati almeno una volta nella generazione di applicazioni Livebase. Questo valore viene aggiornato ogni volta che viene rigenerata un’applicazione contestualmente all’avvio della sua Cloudlet.

Cliccando sulla cifra è possibile inoltre scaricare un report dettagliato in formato Excel (.xlsx). Questo riepilogo mostra gli incrementi di LCP per modello che hanno contribuito al totale degli LCP generati; per ciascun modello è inoltre incluso lo storico delle generazioni nel mese corrente (e relativi incrementi di LCP per generazione).

Componenti interessati: Dashboard Client

A seguito del rimpiazzo dell’engine di una Cloudlet attraverso un modello presente in libreria, i dati relativi ai cambiamenti subiti dal modello precedente (i ModelChanges) non venivano eliminati, e a questi si aggiungevano quelli generati dall’operazione di sostituzione. Questo portava a un’eccessiva proliferazione di ModelChanges che saturava inutilmente lo spazio del Dashboard Database.

Il problema si verificava in quanto la cancellazione dei ModelChanges veniva eseguita solo con la rimozione esplicita dell’engine; questa logica è stata ora inclusa anche nell’operazione di sostituzione.

Componenti interessati: Dashboard Servant

Risolto un problema per cui, tentando di importare record che presentano valori datetime che specificano millisecondi (informazione ancora non gestita da Livebase), veniva sollevato un errore generico anziché indirizzare al download del file Excel con le marcature.

Componenti interessati: Database Importer (ExcelImporter)

È stato riscontrato che, a seguito di importazioni successive, gli ID che venivano assegnati ai record risultavano non sequenziali; questo avveniva in particolare dopo l’importazione di Reference Sheet.

Il problema era dovuto a una gestione errata dell’aggiornamento della tabella @sys@idtable del database, ovvero la tabella che tiene traccia del prossimo ID assegnabile, dovuta a discrepanze tra le diverse strategie di assegnazione degli ID implementate in Livebase. Il problema è stato quindi risolto allineando la strategia di assegnazione degli ID dell’Excel Importer alle altre già presenti.

Componenti interessati: Database Importer (ExcelImporter)

In seguito all’upload di un file SQL che esegue INSERT di record aventi uno qualunque dei campi __createdBy, __lastModifiedBy e __ownedBy vuoti, la Dashboard mostrava il seguente errore nonostante l’importazione si fosse conclusa correttamente:

Column '<EmptyByField>' cannot be null

Il problema era dovuto a un’errata gestione della generazione degli oggetti Singleton, che impostava queste colonne relative a metadati come stringa vuota (mentre nel database della Cloudlet le colonne dei metadati non possono essere nulle). Una successiva operazione di cleanup nel processo di importazione, avente il compito di impostare ogni valore vuoto a null, violava questo vincolo per le colonne relative ai metadati della classe Singleton, scatenando l’eccezione.

La soluzione è consistita nella rimozione di questa operazione di cleanup e nella modifica della creazione dei Singleton, che ora riempie i campi di metadati con il valore system.

Componenti interessati: Dashboard Client

Sono state risolte alcune eccezioni inattese, che rendevano impossibile l’avvio delle Cloudlet. È tuttavia ancora in atto un’analisi per irrobustire le operazioni correlate e ridurre la probabilità di occorrenza di questo errore in futuro.

Componenti interessati: Dashboard, Dashboard Servant

È stato rimosso il componente DatabaseFiller, responsabile della popolazione automatica di un Database con dati casuali. Di conseguenza, non è più contemplata l’operazione di fill e nella finestra di dettaglio del Database non è più presente il pulsante Fill.

Componenti interessati: Dashboard Client, Dashboard Servant

Risolto un problema che impediva la disabilitazione di una classe Form senza attributi; concettualmente, questo scenario è consentito (le classi Form sono le uniche classi a poter non avere attributi), tuttavia non era gestito correttamente dal Designer.

Componenti interessati: Designer (Application Schema)

Risolto un problema per cui, l’operazione alla voce Application permissions menu > Set permission on all classes (raggiungibile facendo click destro su un Permission Schema) modificava, oltre ai grant di tutte le classi attualmente presenti, anche i loro default, con la conseguenza che tali default venivano considerati nelle successive modifiche puntuali dei grant su classi, attributi e relazioni.

Il comportamento del comando è stato corretto per non impattare i default (che ricordiamo possono essere modificati dal pannello Application permissions defaults raggiungibile alla voce Application permissions menu > Default permissions on new elements...).

Componenti interessati: Designer (Permission Schema)

Da febbraio 2021 sarà rimosso dalla piattaforma il supporto al codice deprecato presente nello SPI. Nella documentazione javadoc generata per lo SPI sono sempre presenti i riferimenti al codice che va utilizzato al posto di quello deprecato; ad esempio, le strutture Entity prendono il posto dei Bean e gli Stub sostituiscono i Mock.

Gli sviluppatori Livebase registrati hanno ricevuto una mail con allegata la procedura per l’aggiornamento dei plugin, ove necessario; tale procedura graduale è concepita per abbattere la possibilità di introdurre problematiche nelle applicazioni critiche.

Gli aggiornamenti non dovrebbero comportare più di qualche ora per plugin, che potranno essere pianificate con calma fino alla fine di gennaio, data oltre la quale non supporteremo più i servizi deprecati.

Componenti interessati: Engine Framework (SPI)

È stato introdotto il servizio **getUpdatedAttributes** alla ImmutableEntitySession nello SPI statico che consente di recuperare, a partire dall’ID di una Entity, l’insieme di attributi nativi che sono stati modificati all’interno della sessione di lavoro. Se l’Entity è in creazione, il servizio restituisce tutti gli attributi nativi con valore diverso da null; se è in modifica, restituisce gli attributi nativi che hanno un valore diverso da quello presente su database.

interface ImmutableEntitySession {
  // ...
  public Set<String> getUpdatedAttributes(EntityID id)
}

La ImmutableEntitySession, gia disponibile nel contesto del ValidationHandler, è ora disponibile anche nel contesto di tutti i DatabaseHandler tramite il metodo getCloudletImmutableEntitySession().

Componenti interessati: Engine Framework (SPI)

In previsione del passaggio pianificato dalle strutture deprecate (Bean) alle nuove Entity, è stato introdotto il metodo setDoNotThrowApplicationAccessForbiddenExceptionWorkaround alla EntitySession e alla ImmutableEntitySession nello SPI statico, che consente di disabilitare il controllo sullo stato di abilitazione di ruoli e attributi delle Entity nel contesto della vista applicativa in cui è eseguito il codice del plugin.

A differenza dei Bean, che possono accedere ad attributi e ruoli di una classe senza rispettare la visibilità degli stessi, le Entity devono sottostare alle regole di visibilità (manageability) definite negli Application Schema in cui i plugin sono utilizzati. Se si tenta di accedere a una classe, attributo o ruolo non gestito nella vista applicativa, il framework solleva una tra EntityAccessForbiddenException o EntityAttributeAccessForbiddenException o EntityRoleAccessForbiddenException. Disabilitando questi controlli, è possibile far comportare le Entity come se fossero Bean.

Componenti interessati: SPI Plugin

È stata aggiunta la possibilità di istanziare gli Stub delle Entity (<EntityName>) e delle ImmutableEntity (Immutable<EntityName>) fornendo l’applicazione di riferimento, così da abilitare il controllo sullo stato di abilitazione di classi, attributi e ruoli anche all’interno dei test del codice dei Plugin.

A tale scopo, è stata introdotta nello SPI statico l’interfaccia ApplicationMetadata, che consente di ottenere informazioni sulla manageability di classi, attributi e ruoli nel contesto della vista applicativa in cui è eseguito il codice del plugin. Questa è disponibile nella EntitySession e nella ImmutableEntitySession tramite il metodo getApplicationMetadata().

È possibile quindi iniettare l’applicazione negli Stub Stub<EntityName> passando l’ApplicationMetadata nel costruttore, così che queste classi di test possano eseguire i controlli sulla manageability allo stesso modo delle implementazioni delle Entity e delle ImmutableEntity di produzione.

Componenti interessati: SPI Plugin

È stato aggiunto il parametro insight al servizio Query.<ClassName>__getVersion per il recupero di versioni storiche delle classi storicizzate, introdotto nella versione 5.8.3. Questo parametro, già presente in tutti gli altri servizi GraphQL di lettura (inclusa la versione paginata Query.<ClassName>___getVersionPage), permette di richiedere un dettaglio più o meno esaustivo (a seconda del valore scelto, tra LIGHT e FULL) sulle query SQL eseguite dal servizio. Se la query viene eseguita specificando insight, la risposta, oltre al campo data, conterrà il campo extensions valorizzato.

La signature del nuovo servizio è:

enum InsightType {
  FULL
  LIGHT
}

type Query {
  ClassName___getVersion(_id: ID!, atVersion: Datetime!, insight: InsightType): ClassName
}

Componenti interessati: API GraphQL

Nello scenario in cui una classe è disabilitata a livello di Application Schema (non è managed), ma sono abilitati eventuali ruoli entranti su essa, è ora possibile navigare questi ruoli dal client web dell’applicazione generata, ovvero è possibile aprire la form in sola lettura di tali oggetti. Lo stesso vale se la classe in questione è “spenta” (grigia) a livello di Profile Schema ma non lo sono i suoi ruoli entranti.

Questo case uniforma il comportamento tra il client web e le API GraphQL, in quanto GraphQL permette di navigare gli oggetti associati anche per classi “spente” nell’Application Schema o nel Profile Schema.

Componenti interessati: Engine Builder (client web)

Risolto un problema per cui, in presenza di timezone custom sulla Cloudlet (non-GMT), il parametro di input atVersion del servizio <ClassName>___getVersion veniva considerato come Datetime GMT, a prescindere dalla timezone configurata sul server. Ora anche il parametro atVersion è relativo alla timezone della Cloudlet. I valori dei campi Date ritornati in output continuano a rispettare la timezone custom (come corretto nella versione 5.8.3).

Componenti interessati: API GraphQL

Risolto un problema per cui, a seguito di una modifica su una classe storicizzata, venivano mostrate due versioni identiche. Questo era relativo a un comportamento non convenzionale di MariaDB, che invece di applicare un versionamento a un record (rappresentato dal valore della colonna row_start) per ogni transazione lo fa invece per ogni statement. Le API GraphQL non tenevano conto di questa implicazione, per cui potevano mostrare valori incongruenti.

Nella versione 5.9, per lo stesso problema di MariaDB era stato corretto il recupero del totalCount delle versioni, mentre in questo caso sono stati corretti i valori mostrati per ciascuna versione.

Componenti interessati: API GraphQL

Risolto un problema per cui il server GraphQL andava in errore quando si richiedeva di mostrare attributi derivati per versioni storiche di oggetti restituiti dai servizi Query.<ClassName>___getVersion o Query.<ClassName>___getVersionPage.

Componenti interessati: API GraphQL, Engine Framework (QueryGenerator)

A valle di operazioni di importazione dati sul database della Cloudlet da fonti esterne (file SQL o Excel), il Database Checker si occupa di verificare l’allineamento tra modello e database e segnalare eventuali inconsistenze, come ad esempio violazioni sulle cardinalità dei ruoli.

In precedenza, l’informazione sulle cardinalità effettive dei ruoli era contenuta nel Database Fingerprint, ma è stata rimossa nella versione 5.7.1 per motivi di performance. Pertanto, il Database Checker si rivolge all’Hosting Servant per recuperare queste informazioni e compararle con le cardinalità definite per ciascun ruolo del modello.

Prima dell’intervento, il Database Checker effettuava una singola chiamata per ciascun ruolo con la conseguenza che, al crescere del numero di relazioni nel modello, l’overhead introdotto dalle chiamate diventava un tempo importante.

Per risolvere questo problema di performance, le chiamate sono ora accorpate in un’unica chiamata tra Database Checker e Hosting Servant, il cui risultato viene salvato in memoria ed eliminato al termine della verifica.

Componenti interessati: Database Checker

Nella versione 5.9 è stato aggiunto il pulsante Create Admin al pannello Members of cloudlet <CloudletName>, abilitato solo se non erano presenti utenti con privilegi di amministratore (con attributo admin=true).

La condizione è stata raffinata per consentire di creare più utenti amministratori se l’account della Dashboard ha dei sub-account, uno per ogni sub-account: il pulsante è quindi abilitato quando non esistono utenti con lo stesso username dell’account con cui si è autenticati sulla Dashboard.

Componenti interessati: Dashboard Client

Risolto un problema per cui, in seguito a modifiche al database della Cloudlet (attraverso le operazioni di creazione, copia o rimozione) che adesso comportano anche modifiche alla community, non venivano aggiornati i relativi descrittori; di conseguenza la Cloudlet riportava informazioni non aggiornate, come il conteggio degli utenti. Il problema era dovuto alla mancanza di un’operazione esplicita di refresh del Dashboard Servant.

Componenti interessati: Dashboard Servant

È ora disponibile una classe speciale che rappresenta un utente della Cloudlet: la classe __User. Si tratta di una classe di piattaforma le cui istanze corrispondono con gli attuali Cloudlet member e rappresenta pertanto la Community della Cloudlet all’interno del modello di un’applicazione. Questo nuovo costrutto porta con sé un ripensamento generale del modo con cui verranno gestite le utenze all’interno delle applicazioni Livebase. Il concetto stesso di utente diviene d’ora in poi parte del dominio ed è possibile pertanto espandere le informazioni di un Cloudlet member aggiungendo attributi e relazioni alla classe __User direttamente nel modello.

Modellazione della classe __User

Nel Designer è possibile abilitare la classe __User dalla voce Database menu > New platform class > User oppure dal pulsante della palette(Create platform class User). La classe __User ha di default i seguenti attributi, tutti di tipo string: username, profile e email; oltre a questi, è possibile abilitare tutte le altre informazioni “statiche” relative al Cloudlet member (ad esempio firstName, lastName, etc…) mediante i predefined attributes selezionabili alla voce Class menu > new predefined attribute. Per costruzione, non è possibile dichiarare vincoli unique o index su qualunque attributo di __User, né impostarli required; inoltre, alcuni attributi predefiniti (come profile, language, dateFormat, etc…) hanno domini non modificabili nel modello e possono assumere solo i valori attualmente supportati da Livebase. Il valore dell’attributo profile dipende invece dal nome di uno dei Profile Schema presenti nel modello. Sono supportati attributi di piattaforma e derivati sia di tipo query che math.

È consentito esprimere relazioni di qualunque tipo a partire dalla classe __User e da altre classi verso la classe __User, con l’unica regola che le relazioni uscenti devono avere come cardinalità minima del ruolo target zero; per questo motivo nei Role menu dei target delle relazioni uscenti sono disabilitate le opzioni Exactly one (1,1) e One or more (1,N). Sono consentite sia associazioni che composizioni, tuttavia non è permesso dichiarare attributi derivati su classi part di __User; salvando il modello in questo scenario il Designer mostrerà una issue.

Nelle espressioni è possibile referenziare attributi e/o ruoli della classe __User esattamente come nelle normali classi: la visibilità dipende quindi da dove viene definito il filtro. Non cambia invece la possibilità di referenziare i predefined attributes dell’utente corrente, disponibile con la variabile __CurrentUser.

A livello di Application Schema, la classe __User si comporta esattamente come le normali classi del modello. Tuttavia sarà necessario d’ora in poi che essa sia manageable (abilitata) almeno per una vista applicativa, altrimenti non sarà possibile gestire gli utenti della Cloudlet (vedi più avanti). A livello di Profile Schema, le opzioni impostate nella sezione Management of cloudlet members si riflettono direttamente sui grants della classe __User a livello di Permission Schema, ovvero delle icone ( , , ) sulla classe; cliccando su esse, il Designer mostrerà una issue indicando che questi grant sono gestiti dal Profile Schema.

Gestione degli utenti lato Dashboard

Con l’introduzione della classe __User sono state riviste tutte le operazioni consentite lato Dashboard riguardo la gestione della community delle Cloudlet. Dato che gli utenti sono oggetti di dominio, le informazioni a essi relative verranno memorizzate d’ora in poi nel database della Cloudlet insieme ai dati delle altre classi. Per questo motivo, tutte le operazioni effettuabili sul database (copia, upload/download, backup) ora includono anche le informazioni degli utenti della Cloudlet. Per effetto di questa modifica, le operazioni di modifica di massa sulla community di una Cloudlet (download e delete) non sono più consentite, così come non è consentito il drag & drop di community tra Cloudlet differenti, perché gli utenti possono avere informazioni modellate e quindi essere dipendenti dal particolare modello installato sulla Cloudlet.

Il pannello Members of cloudlet <CloudletName> ora non consente più di creare e/o modificare i membri/utenti della Cloudlet, anche qui perché potrebbero avere informazioni modellate aggiuntive; queste operazioni sono supportate esclusivamente nell’applicazione generata. Resta possibile eliminare uno o più utenti, a patto che questi non abbiano relazioni con altre classi del modello; in questi casi, la Dashboard mostra un messaggio d’errore. L’eliminazione di un utente della Cloudlet non comporta la rimozione dell’oggetto __User dalla tabella relativa del database; per l’utente eliminato viene impostato il flag di sola lettura deleted: true.

È presente inoltre un nuovo pulsante Create Admin, abilitato solo se non sono presenti utenti con privilegi di amministratore (con attributo admin=true). Questo pulsante consente di ri-creare un utente amministratore qualora gli utenti della Cloudlet vengano eliminati (ad esempio eliminando il database). L’utente creato è analogo al default member presente su tutte le nuove Cloudlet e le sue credenziali sono le stesse dell’account con cui si è effettuato login nella Dashboard.

Gestione degli utenti nell’applicazione generata

La gestione degli utenti è supportata in tutta l’applicazione generata:

• nel client web, è stata rimossa la voce Members management dalla homepage; la gestione passa d’ora in poi dalla voce di menu relativa alla classe __User che dovrà essere presente su almeno una delle viste applicative modellate. Ora inoltre non viene più visualizzata nella homepage la lista dei membri facenti parte dello stesso team;
• in ambito Plugin, lo SPI generato include le interfacce Entity per la gestione della classe __User come una normale classe del modello;
• in GraphQL, vengono generati tutti i servizi base di lettura e scrittura per la classe __User, con la differenza nel nome del type: _User invece di __User, dato che l’utilizzo del doppio underscore in GraphQL è riservato ai metadati dello schema.

Anche in GraphQL e da Plugin, l’eliminazione di uno __User comporta l’impostazione del flag deleted=true.

Componenti interessati: Designer (nuovo costrutto, icona nella palette e opzione nel Database menu), Dashboard Client (nuovo pannello gestione membri), Dashboard Servant, Cloudlet Framework, Engine Builder (RuntimeQueryGenerator), Engine Framework (client web, SPI), API GraphQL

Risolto un problema occasionale per cui falliva la renderizzazione grafica del Designer per via di una NullPointerException dovuta alla mancanza di un riferimento. Sono stati irrobustiti i controlli risolvendo problemi di natura generica come questo.

Componenti interessati: Designer

Nella versione 5.8.2 era stato introdotto un processamento della lista delle versioni storiche di un oggetto per risolvere un bug di MariaDB per cui venivano unificate le versioni “vicine” tra loro (considerando “vicine” le versioni comprese in un intervallo di 50ms). Tuttavia, chiedendo tramite GraphQL il conteggio delle versioni storiche di un oggetto (mediante la query <ClassName>___getVersionPage si otteneva un valore errato nel campo totalCount, dovuto al fatto che in questo scenario le versioni unificate venivano conteggiate separatamente.

Componenti interessati: Engine Framework (RuntimeQueryGenerator), API GraphQL

In fase di creazione di dump di Cloudlet da parte dell’Hosting Servant, viene creato un file temporaneo nella cartella /tmp della macchina su cui risiede l’Hosting Servant. Successivamente, questo file viene eventualmente spostato in altre cartelle apposite. La cartella /tmp poteva però essere configurata per avere dei limiti di spazio o di diritti, comportando il possibile fallimento di alcune operazioni (ad esempio, update del database che comporti un dump delle tabelle oggetto di modifica). Per questo motivo, d’ora in poi i file verranno creati nella cartella /database del file system della Cloudlet, invece che nella cartella /tmp dell’Hosting Servant.

È stata inoltre resa configurabile la directory utilizzata da altri file temporanei (ad esempio, quelli legati all’importazione di file Excel), che verranno creati nella cartella indicata dalla proprietà TEMP_DIR dell’Hosting Servant.
Componenti interessati: Hosting Servant

Le API GraphQL sono state aggiornate per utilizzare le interfacce esposte dallo SPI generato relative al controllo dei permessi (grants) definiti nel modello, introdotte nella versione 5.8.3. In precedenza, il controllo dei permessi via GraphQL era realizzato con un’implementazione custom, mentre a partire da ora sarà possibile utilizzare, anche tramite GraphQL, tutte le funzioni attuali e future esposte nello SPI in merito al controllo dei permessi.

Contestualmente, è stata rimossa la generazione dell’endpoint ___Schema/Grants che consentiva l’introspezione dei grants a livello di Application Schema e Profile Schema dell’applicazione generata.

Componenti interessati: API GraphQL

In precedenza, accedendo più volte alla Dashboard con lo stesso account (ad esempio da PC differenti), tutte le sessioni eccetto l’ultima venivano invalidate silenziosamente dal Dashboard Servant, mostrando un errore solamente quando si provava a effettuare una qualunque operazione da una di queste sessioni.

Ora se si effettua un login su una sessione concorrente, la Dashboard rileva la presenza di più sessioni e consente all’utente di decidere se confermare o annullare l’override. In caso di override, le altre sessioni verranno automaticamente reindirizzate al login.

Componenti interessati: Dashboard Client, Dashboard Servant

In seguito alla promozione dei membri della Cloudlet a oggetti di dominio (e quindi di database), è stato deciso di vietare la copia del database tra due Cloudlet se anche solo una tra esse non è up to date (ovvero necessita di un upgrade in seguito a un rilascio Livebase). La stessa precondizione è già presente per l’operazione di clone di Cloudlet.

Componenti interessati: Dashboard Client, Dashboard Servant

Risolto un problema per cui, dopo aver effettuato con successo l’importazione di un foglio Excel, il conteggio degli oggetti presenti nel database non veniva aggiornato automaticamente (era comunque possibile aggiornare il conteggio effettuando Refresh della Dashboard). Ora il refresh non è più necessario in quanto l’informazione viene aggiornata contestualmente.

Componenti interessati: Dashboard, DashboardServant

Nel caso in cui il database di una Cloudlet non contenga oggetti, non ha senso indicare che il conteggio è approssimato, per cui il messaggio (value can be approximate) non compare più nel caso in cui il conteggio sia pari a 0. Al suo posto è mostrato invece il messaggio Database is empty.

Componenti interessati: Dashboard

Risolto un comportamento errato che segnalava false differenze sulle tabelle relative a classi Enum: si verificava qualora si effettuavano modifiche via SQL alla struttura delle tabelle, che portavano eventualmente al riordinamento delle loro colonne rispetto a quello generale, successivo alla loro generazione da parte del Database Coder.

Componenti interessati: Dashboard Client, Database Checker

È stato rimosso il tutorial interattivo che veniva mostrato al primo avvio della Dashboard.

Componenti interessati: Dashboard Client

Sono state introdotte nello SPI generato delle interfacce che permettono di eseguire via Plugin il controllo dei permessi (grants) definiti nel modello a livello di Profile Schema (accesso alle viste applicative) e Permission Schema (permessi su classi, attributi e ruoli). Consulta il dettaglio per maggiori informazioni.

Il controllo dei permessi è disponibile anche all’interno delle risorse REST aggiunte in estensione alla Cloudlet: nella classe RestletServerResource è stato reso disponibile il metodo getApplicationGrants(String applicationName), che ritorna un ApplicationGrants.

Componenti interessati: Engine Framework (SPI)

Le API GraphQL ora supportano l’interrogazione delle versioni storiche delle classi per cui è abilitata la storicizzazione (o system versioning).

Per le classi abilitate, abbiamo esteso la struttura <ClassName> con i seguenti campi:

type ClassName {
  _id: ID
  _clientId: ID
  _versionStart: Datetime # indica l'inizio dell'intervallo di validità della versione (row_start)
  _versionEnd: Datetime # indica la fine dell'intervallo di validità della versione (row_end)
  # ... model-dependent fields
}

È possibile richiedere _versionStart e _versionEnd in qualunque servizio che restituisce la struttura <ClassName> (che rappresenta la versione più recente dell’oggetto).

Vengono inoltre generati i seguenti servizi in lettura:

• Query.<ClassName>___getVersion:

  type Query {
    ClassName___getVersion(_id: ID!, atVersion: Datetime!): ClassName
  }
  

  La versione di <ClassName> ritornata è quella il cui intervallo (row_start, row_end) include il timestamp atVersion passato come parametro.

• Query.<ClassName>___getVersionPage:

  type Query {
    ClassName___getVersionPage(_id: ID!, options: ClassNamePageOptions): ClassNamePage
  }
  

  La <ClassNamePage> ritornata contiene contiene una lista delle versioni storiche dell’oggetto identificato dall’_id; il risultato può essere filtrato e/o ordinato utilizzando tutte le <ClassName>PageOptions pre-esistenti, alle quali è aggiunta la possibilità di ordinare in base ai campi _versionStart e _versionEnd. La struttura <ClassName>Sort aggiornata:

  input ClassNamePageOptions {
    orderBy: [ClassNameSort!] = [_id___ASC]
    # ... other options
  }
  
  enum ClassNameSort {
    _id___ASC
    _id___DESC
    _versionStart___ASC
    _versionStart___DESC
    _versionEnd___ASC
    _versionEnd___DESC
    # ... model-dependent values
  }

Componenti interessati: API GraphQL

I servizi GraphQL di invocazione per FormActionHandler (sia il servizio generico Mutation.<ClassName>___formAction___<HandlerName> che quelli specifici di Create o Update) accettano ora il parametro di input opzionale forceWarnings per bypassare eventuali Class warning non bloccanti valutati durante l’esecuzione dell’Handler, che normalmente bloccherebbero l’invocazione del Plugin via GraphQL. Tale parametro era già accettato da tutti i servizi di scrittura (save, create, update, delete).

Componenti interessati: API GraphQL

Prima dell’intervento, le API REST (deprecate ormai in favore delle API GraphQL) continuavano a essere generate per tutti i modelli, comportando un peso prestazionale nel processo di build. I test condotti (di cui riportiamo un esempio in fondo) hanno evidenziato una riduzione della quantità di codice generato, significativa per modelli grandi; tale riduzione consente di ridurre sia i tempi di generazione che quelli di compilazione, portando quindi un duplice beneficio. È stata inoltre condotta un’indagine per individuare i clienti che attualmente fanno uso in produzione delle API REST.

Per snellire il processo di build della Cloudlet, è stata quindi resa opzionale la generazione delle API REST per tutti i nuovi clienti Livebase e per i clienti pre-esistenti che sappiamo non utilizzare le REST, mentre resta abilitata la generazione per i clienti pre-esistenti che utilizzano le REST così da non garantire disservizi. Contattando il team Fhoster sarà possibile richiedere di abilitare le REST - che ricordiamo essere deprecate - finché non verrà abbandonato del tutto il supporto.

Sulla Dashboard, nel caso in cui le REST non siano abilitate per la Cloudlet, il pannello informativo API & Public URLs riporterà questa informazione nella sezione API REST, così come avviene per le API GraphQL.

Componenti interessati: Engine Builder, Dashboard Client, Dashboard Servant

Risolto un problema per cui, in presenza di timezone custom sulla Cloudlet (non-GMT), si ottenevano valori errati in risposta alle chiamate GraphQL per campi di tipo date. Tale problema dipendeva dalla versione del DBMS utilizzato dalla Cloudlet ed era dovuto a un disallineamento nella gestione della timezone.

Componenti interessati: API GraphQL

Risolto un problema relativo alla gestione del campo clientId: inviando al server una richiesta contenente il campo clientId valorizzato null e richiedendo in output lo stesso valore, il server restituiva clientId: "null", ovvero una stringa invece del valore null vero e proprio.

Componenti interessati: API GraphQL

Risolto un problema per cui falliva la generazione dello schema quando nel modello era presente almeno una classe part di tipo Form (ovvero una composizione tra due classi Form), dovuto alla mancata generazione delle strutture di input <PartFormClassName>RoleObject(s), di supporto ai servizi di Update. Ora tali strutture vengono generate correttamente.

Componenti interessati: API GraphQL

Risolto un problema in fase di build del modello che consentiva al primo profilo presente (Profile Schema) di accedere a tutte le viste applicative (Application Schema) che non avevano alcun profilo assegnato. Il problema era dovuto al pre-processamento del modello, per cui veniva erroneamente il primo profilo disponibile alle applicazioni “orfane”.

Componenti interessati: Engine Builder

È stata modificata la gestione, da parte del Dashboard Servant, della tabella delle sessioni attive degli account; ciò ha consentito di risolvere alcuni scenari d’errore per cui, qualora per un account si verificassero crash della Dashboard o altri fallimenti, tale account finiva in uno stato inconsistente (under maintenance), impedendo successivi login sulla Dashboard.

In particolare, poteva capitare che lo stato inconsistente (under maintenance) di un sub-account impedisse l’accesso alla Dashboard anche ai sub-account “fratelli” su cui non si erano verificati errori.

Componenti interessati: Dashboard Servant

In alcuni scenari poteva accadere che l’operazione di cancellazione di una Cloudlet sull’Hosting Servant, pur andando a buon fine, impiegasse più tempo del timeout consentito da cxf per i servizi sincroni; per questo motivo, il Dashboard Servant non era informato del successo e l’account associato alla Cloudlet rimossa finiva in uno stato inconsistente, impedendo successivi login sulla Dashboard con tale account.

Il problema è stato risolto rendendo asincrona l’operazione di cancellazione di una Cloudlet dell’Hosting Servant e adattando i servizi correlati del Dashboard Servant: dopo aver avviato la cancellazione, il controllo ritorna immediatamente al Dashboard Servant, che si mette in polling in attesa della conclusione dell’operazione.

Componenti interessati: Dashboard Servant, Hosting Servant

La struttura del database generato della Cloudlet è stata aggiornata per supportare il log dell’operazione automatica di rimozione delle tabelle di supporto al processo di importazione, introdotta nella versione 5.8.2.

Componenti interessati: Database Importer

Risolto un problema relativo a un recente cambiamento nella logica di inferenza dei tipi, per cui falliva l’importazione di fogli Excel in presenza di attributi booleani. La logica di inferenza degli attributi booleani è stata correttamente ripristinata per esaminare almeno due record con valori univoci, requisito necessario per riconoscere i due valori “vero” e “falso”.

Componenti interessati: Database Importer (Excel Importer)

Risolto un problema relativo al rendering di componenti grafici per cui la Dashboard andava in eccezione dopo aver eliminato un backup di una Cloudlet dal pannello Backups della Dashboard. Il problema, di natura generica e di difficile riproduzione, è stato risolto irrobustendo alcuni controlli effettuati prima del rendering dei componenti.

Componenti interessati: Dashboard Client

La gestione delle risorse per gli account è una feature in via di abbandono progressivo in favore delle nuove politiche di pricing della piattaforma. In questa ottica, è stata rimossa tutta la logica lato server relativa al calcolo e al controllo delle risorse assegnate, allocate e utilizzate dalle Cloudlet associate agli account Livebase; in particolare, è stato rimosso dal pannello Cloudlets della Dashboard la view Resources management (resta ora presente l’unica opzione Configuration, command & control).

Livebase non terrà più traccia delle quote imposte sulle risorse della Cloudlet relative a numero massimo di membri online, numero massimo di oggetti nel database, traffico mensile e dimensione del file storage.

Contestualmente, è stato scelto di rendere il conteggio approssimato la tecnica di default per tutte le count effettuate a fini statistici sulle tabelle database della Cloudlet. Questa tecnica è basata su un approccio offerto nativamente dal DBMS ed è supportata dal Cloudlet Framework a partire dalla versione 5.6.2 come alternativa più performante della count tradizionale. Ciò consente di ottenere un miglioramento di performance in fase di caricamento della Dashboard, specialmente se l’account possiede Cloudlet con database nell’ordine del milione di record.

Di conseguenza, l’interfaccia è stata modificata nei seguenti punti per veicolare l’informazione che il numero mostrato non è preciso:

• il pannello Cloudlets della Dashboard ora riporta la dicitura (value can be approximate) sotto alla conta degli oggetti nel database;
• il pannello Database of Cloudlet <CloudletName> -> Content overview riporta la dicitura (approximate) nell’intestazione della colonna Objects;
• nel Designer aperto in modalità database_aware (modello installato su una Cloudlet su cui è presente un database) ora compare una tilde (~) accanto al numero di oggetti in fondo alle classi.

Componenti interessati: Dashboard Client (pannello Cloudlets, pannello Database) , Dashboard Servant, Designer (count degli oggetti sulle classi), Engine Framework, Cloudlet Framework, Hosting Servant

I caratteri di indicazione degli stereotipi di Enum e Singleton ora sono i simboli speciali « e ».

Componenti interessati: Designer

Il framework è stato adeguato per aggirare un problema noto di MariaDB, che si presenta nella gestione del system versioning quando si usano le colonne row_start e row_end di tipo timestamp (scenario utilizzato da Livebase). La gestione dei timestamp attuale fa sì che si utilizzi l’istante dello statement anziché della transazione; ciò significa che, quando più righe vengono inserite in un’unica transazione (in Livebase avviene quando si persiste un part con il suo whole), le due righe avranno timestamp leggermente diversi.

Di conseguenza, in Livebase accadeva che la lista delle versioni mostrasse versioni duplicate, create a pochi millisecondi di distanza (causate dal persist delle classi part), mentre il retrive di una singola versione poteva essere incompleto (manca il part, in quanto creato un istante dopo).

Noti questi problemi, la lista delle versioni è stata modificata per unificare le versioni “vicine” tra loro (considerando “vicine” le versioni comprese in un intervallo di 50ms).

Componenti interessati: Engine Framework (RuntimeQueryGenerator)

Durante l’importazione dati, il database della Cloudlet viene usato per memorizzare delle tabelle di supporto, con prefisso @sys@importer. Queste tabelle non venivano toccate ulteriormente una volta terminato il processo, a prescindere dall’esito. Il processo è stato modificato per attuare la seguente gestione:

• nel caso in cui l’importazione vada a buon fine, le tabelle di supporto vengono automaticamente rimosse;
• nel caso in cui l’importazione fallisca, le tabelle tabelle vengono mantenute come strumento utile per il debug;
• nelle importazioni successive con successo, tutte le tabelle di supporto (anche quelle relative a importazioni fallite) vengono rimosse.

Componenti interessati: Database Importer, Hosting Servant

È stata modificata la precedenza dei controlli effettuati dal Designer per garantire la validità delle relazioni nel modello. Nel caso di ruoli su classi Enum, Singleton e Form, per cui esistono regole specifiche (niente ruoli che partono da Enum, niente ruoli che arrivano su Singleton o Form), queste vengono controllate prima di altre regole comuni a tutto il modello. Grazie a questa modifica, il messaggio d’errore mostrato per queste classi è più specifico.

Componenti interessati: Designer (gestione issue)

Risolto un problema del Designer per cui, impostando manualmente il path di una query nel Query expression editor, eventuali filtri WHERE definiti sulla stessa non venivano valutati correttamente.

Componenti interessati: Designer (Database Schema, Query expression editor)

Risolto un problema del Designer per cui la creazione automatica di query path (trascinando un attributo e selezionando Link here) risultava in un path privo di eventuali loop anche in presenza di tali.

Componenti interessati: Designer (Database Schema)

Risolto un problema del Designer per cui, in presenza di attributi required su cui era impostato un valore di default, le icone required (!) e il simbolo del valore di default (◀) apparivano sovrapposte; ciò avveniva solamente per attributi con nome più lungo della larghezza di default della classe.

Componenti interessati: Designer (Application Schema)

Sono state sperimentate diverse soluzioni per ottenere un miglioramento delle prestazioni della compilazione del codice Java generato a partire dal modello. Dopo aver esplorato la strada della compilazione incrementale (vedi commento), sono stati condotti dei test per confrontare il compilatore standard javac, attualmente utilizzato dall’Engine Builder, con il più performante EclipseJ.

I test (di cui riportiamo un esempio in fondo) hanno evidenziato una riduzione media del tempo di compilazione di circa il 40%. Per questo motivo, l’Engine Builder è stato modificato per utilizzare come default il nuovo compilatore EclipseJ; ciò si traduce in un aumento globale delle prestazioni dell’operazione di Start delle Cloudlet che coinvolge il build dell’applicazione generata.

Componenti interessati: Engine Builder, Dashboard Servant

È stata aggiunta l’informazione sullo stereotipo nella documentazione generata di strutture e servizi di classi Enum e Singleton, così poterle distinguere più facilmente dalle normali classi. Questo consente agli sviluppatori GraphQL che non hanno accesso al modello di ottenere informazioni sulla natura di ciascuna classe.

Componenti interessati: API GraphQL (schema builder)

Risolto un problema per cui il servizio generico per classi Form Mutation.<FormClassName>___formAction___<HandlerName> (introdotto nella versione 5.8) non utilizzava correttamente la struttura save generica, causando il fallimento di richieste di questo tipo.

Componenti interessati: API GraphQL

Risolto un problema relativo al servizio generico Mutation.<ClassName>___save (introdotto nella versione 5.8) per cui non era possibile cancellare ruoli o part a 1 impostando il loro valore a null.

Componenti interessati: API GraphQL

Risolto un problema di concorrenza nell’accesso a variabile System fatto tramite chiamate GraphQL.

Componenti interessati: Engine Framework

Risolto un problema per cui, richiamando via GraphQL un FormActionHandler al cui interno veniva richiamato il metodo entitySession.persist() si ottenevano due effetti collaterali:

• se si cercava di apportare modifiche all’entity form dopo il persist veniva lanciata una eccezione di tipo EntityNotFoundException;
• a prescindere, GraphQL restituiva di ritorno il campo data nullo;

Il problema era causato da un disallineamento nella gestione della sessione da parte delle API GraphQL rispetto all’applicazione generata.

Componenti interessati: Engine Framework

Sul client web è possibile abilitare una voce di menu per visualizzare la lista globale degli oggetti di una classe part da cui è possibile solo leggere o editare gli oggetti pre-esistenti. È stato risolto un errore per cui falliva l’invocazione di un FormActionHandler definito su tale classe part e invocato dalla form di un oggetto part aperto dalla lista globale. L’errore era dovuto a una mancata inizializzazione, nel contesto in memoria, dell’oggetto whole relativo.

Componenti interessati: Engine Framework

Il pannello informativo della Cloudlet API & Public URLs è stato aggiornato per includere i link agli endpoint GraphQL. Per ciascuna vista applicativa <ApplicationName> modellata, viene generato un endpoint GraphQL dedicato all’indirizzo <CloudletName>/auth/api/graphql/<ApplicationName>.

Il Dashboard Servant è stato aggiornato con un nuovo servizio per ottenere i link degli endpoint GraphQL della Cloudlet.

Componenti interessati: Dashboard Client, Dashboard Servant

Il pannello Extensions of cloudlet <CloudletName>, raggiungibile dalla voce del Cloudlet Menu () Manage plugins () è stato rinominato in Plugins of cloudlet <CloudletName>. Inoltre, sono state aggiornate:

• la descrizione, che ora contiene i link ai Javadoc generati delle due API (Plugin e Framework);
• la lista dei plugin installati;
• il pulsante Upload (rinominato in Upload plugin e spostato accanto al pulsante Download SPI).

Componenti interessati: Dashboard Client

Sono state aggiunte informazioni nel log della Dashboard relative alle seguenti operazioni:

• cambiamento dello stato di un Plugin da start a stop o viceversa (aggiunto il log mancante, include il nome del Plugin);
• download di un Plugin (aggiunto il nome del Plugin);
• rimozione di un Plugin (aggiunto il log mancante, include il nome del Plugin);
• installazione di un engine (aggiunta la versione del modello);

Componenti interessati: Dashboard Servant

È stato aggiornato il messaggio d’errore che viene mostrato in caso di fallimento dell’operazione di Backup di una Cloudlet per includere il nome della Cloudlet.

Componenti interessati: Hosting Servant

È stata ripristinata la possibilità di importare fogli Excel contenenti relazioni riflessive, siano esse associazioni o composizioni. Era presente infatti un errore nell’ordine di validazione delle relazioni per cui non venivano trovati i record puntati anche se correttamente presenti sul database.

Ora è possibile importare associazioni riflessive usando reference sheet o relation sheet, e composizioni riflessive usando reference sheet; su questi va sempre inclusa, per ciascun record part, una chiave al record whole puntato, che può essere formata da uno da più attributi. In ogni caso, tutti i fogli del file Excel devono sempre garantire l’atomicità dell’importazione.

Componenti interessati: Database Importer (Excel Importer)

Un Singleton è una nuova tipologia di classe che ammette un’unica istanza all’interno dell’applicazione generata ed un unico record nella corrispondente tabella del database. I Singleton sono utili per esprimere nel modello informazioni configurabili a visibilità globale. Come per le classi Enum, infatti, i Singleton sono accessibili da tutte le altre classi del modello; a esse è consentito referenziare attributi delle istanze Singleton nelle espressioni math, WHERE e filtri senza doversi associare alla classe stessa.

Come per i literal object degli Enum, la presenza di una classe Singleton nel modello garantisce l’esistenza della sua istanza nel database e nell’applicazione generata; tuttavia, mentre i literal object degli Enum sono definiti e valorizzati direttamente a livello di Database Schema, le istanze Singleton devono essere valorizzate nell’applicazione generata editando l’oggetto come avviene per normali classi. Nonostante ciò, è possibile modellare a livello di Application Schema dei valori di default per gli attributi dell’istanza Singleton.

Modellazione di Singleton

Nel Designer è possibile dichiarare classi Singleton dalla voce Database menu > New singleton class oppure dal pulsante della palette(Create a new singleton). In alcuni scenari supportati (vedi dettaglio) è inoltre possibile promuovere una normale classe a Singleton dalla voce Class menu > Convert to singleton.

Una classe Singleton è distinguibile nel diagramma per lo stereotipo <<singleton>>. È consentito dichiarare attributi nativi di tutti i tipi (a eccezione di serial) e derivati sia di tipo math sia query; è possibile inoltre abilitare tutti gli attributi platform. Per costruzione, non è possibile dichiarare vincoli unique o index sugli attributi del Singleton, né impostarli required. Non è consentito esprimere relazioni verso il Singleton (non avrebbe infatti senso, dato che l’istanza è unica ed è visibile globalmente), mentre è consentito esprimere relazioni dal Singleton verso le altre classi del modello, inclusi gli Enum, purché la cardinalità minima del ruolo target sia zero; per questo motivo nei Role menu sono disabilitate le opzioni Exactly one (1,1) e One or more (1,N). Sono consentite sia associazioni che composizioni, pertanto è possibile dichiarare anche attributi derivati di tipo query sui ruoli del Singleton.

Nelle espressioni è possibile referenziare attributi e/o ruoli del Singleton con la stessa sintassi degli Enum, ma lasciando le parentesi quadre vuote: <SingletonClassName>[].<AttributeName>. Nell’Expression editor, inoltre, i Singleton sono elencati in una lista accessibile dal pulsante (Singleton constants), da cui è possibile selezionarne attributi e/o ruoli.

Come già detto, l’istanza Singleton è gestita nell’applicazione generata; pertanto, a livello di Application Schema, il Singleton è manageable e può essere attivato/disattivato come una normale classe; è possibile editarne la voce di menu, il Form layout, il Print layout e i Class warning. Per i Class warning, gli unici eventi disponibili sono open, edit e SaveExisting. Infine, come già detto è possibile impostare default expression sugli attributi del singleton.

Singleton nell’applicazione generata

Dato che l’esistenza dell’istanza è sempre garantita, gli unici servizi CRUD generati sono quelli relativi all’edit di tale istanza, mentre non vengono generati servizi per crearla o eliminarla:

• nel client web, per le viste e per i profili abilitati è disponibile una voce di menu che consente di accedere direttamente alla Form dell’istanza Singleton senza passare per alcuna vista tabellare.

• in ambito Plugin, è supportato un sottoinsieme di Service Handler dichiarabili nel modello. Nello SPI, è possibile ottenere riferimenti alle istanze singleton tramite i servizi getEntity e getImmutableEntity della EntitySession, che richiedono solo il nome della classe Singleton e non l’id come per le normali classi.

  Dettaglio: Service Handler supportati per Singleton

• in GraphQL, è supportato un sottoinsieme di servizi per classi Singleton (vedi dettaglio);

  Dettaglio: Servizi GraphQL supportati per Singleton

Singleton e manutenzione evolutiva

Dal momento che la classe Singleton non è altro che una normale classe la cui cardinalità di tabella è bloccata a 1, la maggior parte degli scenari di manutenzione evolutiva per Singleton erano già supportati dal Database Checker. È stato aggiunto un controllo per lo scenario in cui, in seguito all’operazione Convert to Singleton, una normale classe viene promossa a Singleton.

Componenti interessati: Designer (nuovo costrutto, icona nella palette e opzione nel Database menu), Database Checker (supporto scenari singleton), Engine Builder (QueryGenerator e RuntimeQueryGenerator, supporto alla nuova sintassi), Engine Framework (client web, SPI), API GraphQL

Nella versione 5.5.3 sono stati introdotti gli LCP (Livebase Complexity Points) come punteggio per rappresentare la complessità dei modelli.

Il punteggio dei modelli veniva mostrato già nel Designer e a fianco dei modelli nella Engine Library. Questa informazione è stata estesa ai modelli installati sulle Cloudlet (engine): il punteggio LCP è mostrato nel riquadro Cloudlet e viene aggiornato al salvataggio del modello.

Componenti interessati: Dashboard Client (pannello Cloudlet), Dashboard Servant

Risolto un problema del Designer per cui l’eliminazione di una classe part dal Database Schema causava, nei Permission Schema in cui quella classe era abilitata, la modifica a readonly del grant sulla classe; questo effetto si propagava inoltre su tutte le classi main a essa connessa, e su tutte le altre classi part raggiungibili da tali main.

Componenti interessati: Designer (Permission Schema)

Risolto un problema del Designer relativo al fix automatico di issue relative ai Class warning. Il problema era dovuto a una gestione errata delle variabili nelle espressioni del warning valutate sull’evento onCreate.

Componenti interessati: Designer (gestione issue)

Prima dell’intervento, alcune strutture dati e servizi della API esistevano in due varianti: Create e Update; ciò vale, oltre che per i servizi stessi di creazione e modifica, anche per i servizi preview e validate. I motivi dietro questa diversificazione risalgono al voler offrire un meccanismo prevedibile e self-documented per interrogare le applicazioni Livebase.

Nel progettare applicazioni che utilizzano intensivamente le API GraphQL (a es. client web), una tipizzazione rigida può tuttavia rappresentare un limite, specialmente nei casi in cui non è necessario avere, lato client, strutture dati che differiscono relativamente poco, come è il caso per le strutture Create e Update.

Alla luce di questa riflessione, sono stati introdotti nuovi servizi generici che mettono a fattor comune queste differenze (save, preview, validate e formAction), e che utilizzano strutture di input flessibili (draft), in grado di assumere il significato di una Create o Update a seconda dei campi valorizzati. Consulta i dettagli per maggiori informazioni.

Componenti interessati: API GraphQL (schema builder)

In precedenza, per endpoint dove la platform class __User è abilitata, gli utenti creati con il servizio Mutation.__User___create erano abilitati solamente se sulla classe era stato esplicitato il predefined attribute __User.enabled. Ciò risultava nella creazione di membri disabilitati impossibilitati ad accedere alla Cloudlet; il problema era risolvibile abilitando l’attributo e rigenerando le GraphQL. Il framework è stato sofisticato per rendere automatica questa soluzione, pertanto i nuovi utenti creati via GraphQL ora sono sempre abilitati di default.

Componenti interessati: Engine Framework

Risolto un fallimento del build che si presentava quando nel modello erano presenti attributi query con delle WHERE in cui si faceva uso di attributi di Enum. Il Query Generator è stato rifattorizzato per riconoscere correttamente i letterali Enum nei filtri.

Componenti interessati: Engine Framework (Query Generator)

Risolto un fallimento del build che si presentava quando si aggiornava un modello aggiungendo un vincolo di unicità che coinvolgeva attributi contenenti lettere maiuscole. Il problema era dovuto a un errato mapping del Database Checker nella creazione del vincolo, per via delle lettere maiuscole.

Componenti interessati: Database Checker

In alcuni scenari, lo start di una Cloudlet con un modello contenente classi Form causava la segnalazione di una falsa incompatibilità tra modello e Database; il problema era causato dalla mancata gestione delle tabelle delle classi Form nel database temporaneo usato nel controllo di incompatibilità. L’Hosting Servant è stato modificato per ignorare tutte le tabelle per cui non possono verificarsi incompatibilità, tra cui quelle delle classi Form.

Componenti interessati: Hosting Servant

Il pannello informativo della Cloudlet API & Public URLs è stato aggiornato per includere un link al client GraphiQL, disponibile per le Cloudlet con GraphQL abilitate all’indirizzo <CloudletName>/auth/api/graphql/asset/index.html. Il link non è presente se le GraphQL non sono abilitate.

Contestualmente, le API REST sono state deprecate in favore di GraphQL. I link all’endpoint REST nei vari formati sono ora raggruppati in una sessione collassata.

Componenti interessati: Dashboard Client

L’abilitazione della storicizzazione (o system versioning) su una classe comporta l’aggiunta, alla relativa tabella del database, delle colonne row_start e row_end; l’assenza di tali colonne dal backup della struttura del DB non consentiva il successivo restore. I Database Coder e Updater sono stati sofisticati per gestire in modo esplicito le colonne relative alla storicizzazione sia nello scenario di creazione di una tabella storicizzata, che nella successiva abilitazione/rimozione del versioning da una tabella esistente.

Componenti interessati: Database Coder, Database Updater

Nella versione 5.7.1 era stato aggiunto un controllo delle cardinalità dei ruoli espressi nei Reference Sheet (fogli Excel contenenti nuovi record e relazioni); tale controllo è stato esteso anche ai Relation Sheet, ovvero fogli Excel che aggiungono relazioni tra record esistenti, senza aggiungerne nuovi. Sono supportate tutte le possibili configurazioni di cardinalità, incluse cardinalità custom, e sono controllate anche le associazioni riflessive.

In caso di violazioni delle cardinalità, i record del foglio Excel interessati vengono opportunamente marcati, affinché l’utente possa risolvere agevolmente l’errore. L’eventuale individuazione di errori interrompe il processo di importazione e non lascia il database in uno stato inconsistente.

Componenti interessati: Database Importer (Excel Importer)

Nel momento in cui viene importato un Relation Sheet o un Reference Sheet, una nuova fase del processo di validazione comprende ora il controllo dei vincoli di unicità definiti su combinazioni di ruoli della main table o di una delle tabelle coinvolte nell’associazione di riferimento. Il vincolo deve essere rispettato sia dai dati di nuova importazione che da quelli già presenti.

In caso di violazioni del vincolo, i record del foglio Excel interessati vengono opportunamente marcati, affinché l’utente possa risolvere agevolmente l’errore. L’eventuale individuazione di errori interrompe il processo di importazione e non lascia il database in uno stato inconsistente.

Componenti interessati: Database Importer (Excel Importer)

Nel momento in cui veniva importato un foglio Excel contenente dati che non soddisfano alcuni vincoli di dominio, il server segnalava un errore generico ma non venivano evidenziate issue sul database, che conteneva comunque alcuni dati errati. È stato corretto un errore nell’operazione del Dashboard Servant responsabile del processo di importazione che causava un reset del Database Compatibility Report e, di conseguenza, il mancato aggiornamento delle issue. Inoltre, il messaggio d’errore mostrato sulla Dashboard è ora più specifico.

Componenti interessati: Dashboard Client, Dashboard Servant

Nel portale, quando è stata rimossa la gestione dei pagamenti è stato introdotto il concetto di licenza Livebase: ogni account ha associata una licenza con relativo tipo e scadenza della stessa.

Nel caso in cui la licenza di un account fosse scaduta, effettuando login col suddetto si otteneva un errore di visualizzazione nella sezione My account. L’operazione di recupero è stata modificata per andare sempre a buon fine: il portale mostrerà le informazioni relative alla licenza anche se questa è al di fuori del periodo di validità.

Componenti interessati: Portale

Sono stati migliorati i seguenti menu:

• Class menu > New relation: le opzioni disponibili vengono abilitate/disabilitate condizionatamente al fatto che la classe supporti o no quella relazione; se tutte e tre le voci sono disabilitate, anche il menu padre viene disabilitato. Questo vale per tutte le tipologie di classi esistenti;
• Role menu: le opzioni disponibili per la cardinalità vengono disattivate in tutti i casi in cui quella opzione non è ammessa. Nel momento in cui viene impostata una certa cardinalità, questa viene controllata e in caso di errori verrà sollevata un’eccezione.

Componenti interessati: Designer (Database schema)

Corretto un comportamento errato dell’algoritmo di costruzione del TreePath per cui, nel caso di query che navigano relazioni riflessive, l’albero disegnato non rifletteva correttamente l’espressione.

Componenti interessati: Designer (Database schema)

Il Dashboard Servant effettuava un controllo sui nomi di modelli/engine di tipo case sensitive, mentre sul Client il controllo era case insensitive. Per questo motivo, era consentito avere più modelli in libreria il cui nome conteneva stessi caratteri ma con case diverso. Tuttavia, il server andava in eccezione se si provava ad aprire uno di questi modelli/engine.

Per risolvere il disallineamento, il controllo è stato sofisticato lato Client, impedendo del tutto la coesistenza di modelli/engine con nomi con stessi caratteri e case diversi, e mostrando un’eccezione se si tenta il rename di un modello come descritto.

Componenti interessati: Dashboard Servant

Rinominato lo stereotipo nell’header delle classi Enum. Sono stati rinominate inoltre la label del pulsante della palette(Create a new enum) e la voce Database menu > New enum class.

Componenti interessati: Designer (Database schema)

Il Database Fingerprint è un insieme di meta-informazioni relativi al database di una Cloudlet che riguardano il numero di record effettivamente presenti in ciascuna tabella, e la molteplicità reale dei ruoli di ciascuna relazione. Queste informazioni sono utilizzate dal Database Checker per determinare la compatibilità del database con il modello e stilare il relativo Database Compatibility Report, contenente eventuali compatibility issue. In particolare, il Checker necessita di conoscere le cardinalità effettive di tabelle e relazioni per determinare il livello (low, medium o high) di severità del disallineamento.

Prima dell’intervento, il Fingerprint veniva calcolato con un approccio eager; tuttavia, il tempo necessario per recuperare le cardinalità effettive di tutte le tabelle e relazioni cresceva in modo significativo all’aumentare del volume dei dati presenti nel database della Cloudlet.

Osservando che nella maggioranza dei casi il Checker necessita di sapere solamente se la tabella ha record o meno (per classificare issue di livello low o medium), per ottimizzare le performance è stato introdotto un approccio lazy:

• il Fingerprint viene ora calcolato omettendo l’informazione sulle cardinalità e impostando un valore booleano sulle tabelle (hasRecords), indicativo della presenza di record o meno; questo flag è molto rapido da calcolare in tutti gli scenari;
• il Database Checker ora richiede all’Hosting Servant solo le cardinalità di cui necessita effettivamente; ad esempio, nel caso delle foreign key, vengono chieste solo le cardinalità delle tabelle interessate dalle modifiche;
• i valori sulle cardinalità di tabelle e foreign key sono posti in una cache, separata dal Fingerprint, che continua a mantenere solo informazioni statiche sulla struttura delle tabelle.

Componenti interessati: Dashboard Servant, Database Checker (modificato processo di retrieve delle cardinalità), Hosting Servant (CloudletDatabaseManager, nuovi servizi per retrieve di cardinalità)

Risolto un problema di classpath che impediva il corretto funzionamento della generazione dei Report.

Componenti interessati: Engine Builder

Risolto un problema per cui, da GraphQL, i valori di attributi query sulla classe __CurrentUser usati nelle math expression assumevano valore nullo. È stato modificato un servizio usato dalla API che inizialmente restituiva solamente gli attributi statici (nativi, system e default della classe User), affinché restituisse anche attributi derivati.

Componenti interessati: API GraphQL, Engine Framework (RuntimeQueryGenerator)

È stata cambiata la gestione dell’attributo _clientId per essere trattato come stringa. In questo modo è possibile usarlo nel filtraggio di query paginate (come ad esempio su oggetti part), senza ottenere eccezioni. Prima era possibile aggirare il problema inserendo il valore tra apici, ora non è più necessario.

Componenti interessati: API GraphQL

Accedendo al client GraphiQL di una Cloudlet con SSO abilitato, il caricamento della pagina index.html si bloccava per via di un errore 401 sulla richiesta per ritornare le applicazioni GraphQL disponibili. Le chiamate effettuate sono state modificate per funzionare correttamente anche con SSO.

Componenti interessati: API GraphQL (client)

In Keycloak, gli username vengono memorizzati nel JWT case insensitive, mentre nel database della Cloudlet sono case sensitive. Per via di questo disallineamento falliva il controllo dello username sul DB, impedendo il login a utenti con username contenenti maiuscole su Cloudlet con SSO abilitato. Il controllo è stato rilassato per supportare la case-insensitivity di Keycloak.

Componenti interessati: Engine Framework

Nel momento in cui viene importato un Reference Sheet (foglio Excel contenente nuovi record e relazioni), una nuova fase del processo di validazione comprende ora il controllo delle cardinalità dirette e/o inverse sia in riferimento ai dati di nuova importazione, che a quelli già esistenti nel database.

In caso di violazioni delle cardinalità, i record del foglio Excel interessati vengono opportunamente marcati, affinché l’utente possa risolvere agevolmente l’errore. L’eventuale individuazione di errori interrompe il processo di importazione e non lascia il database in uno stato inconsistente.

Componenti interessati: Database Importer (Excel Importer)

Se dopo un’operazione import data su una Cloudlet venivano sollevate issue dovute a incompatibilità dei dati (a es. violazioni sul dominio degli attributi) e l’utente effettuava un Force check database sulla stessa, in alcuni casi le issue sollevate scomparivano. L’operazione di force check è stata modificata in modo da forzare il controllo sui dati se sono presenti violazioni dei vincoli.

Componenti interessati: Dashboard Servant

Aggiunto al clone di una Cloudlet la configurazione dei system plugin a essa collegati; questo risolve un problema per cui il clone di una Cloudlet con le GraphQL abilitate non aveva la medesima abilitazione.

Componenti interessati: Dashboard Servant

Effettuando login con un sub-account, il portale mostrava, nella sezione My account, la pagina con il vecchio launcher della Dashboard invece dell’installer attuale. Il portale è modificato per uniformare la pagina del sub account a quella dell’account master, che ora mostra l’installer della Dashboard con il corretto link per scaricarlo (il default dipende dal sistema operativo utilizzato).

Componenti interessati: Portale

Un Enum è una nuova tipologia di classe che consente di dichiarare, direttamente nel modello, oggetti costanti a visibilità globale (detti literal objects, letterali) che possono essere usati dalle altre classi nel dichiarare espressioni math, condizioni WHERE sulle query o filtri su classi e ruoli a livello di Application Schema. Come in UML, è possibile esprimere ruoli di associazione verso un Enum così da associare oggetti di una classe ai singoli letterali. Gli Enum sono utili per esprimere nel modello informazioni statiche, come un elenco di stati o classificazioni da assegnare a singoli oggetti.

Modellazione di Enum

Nel Designer è possibile dichiarare classi Enum dalla voce Database menu > New enum class oppure dal pulsante della palette(Create a new enum). Una classe Enum è distinguibile nel diagramma dallo stereotipo <<enumeration>>, e per la presenza di due liste: attributi e literal objects; è possibile aggiungere letterali selezionando Class menu > New literal. Tutti i letterali hanno sempre l’attributo name, una stringa uppercase univoca nel contesto della classe in cui è dichiarato; il name è obbligatorio in quanto identifica il letterale stesso nella lista dei literal objects. Nelle espressioni è possibile referenziare il letterale con la nuova sintassi <EnumClassName>[LITERAL_NAME].name. Nell’Expression editor, inoltre, Enum e letterali sono elencati in una lista accessibile dal pulsante (Enum constants), da cui è possibile selezionare gli attributi.

È possibile dichiarare letterali complessi composti da più campi definendo altri attributi sulla classe Enum. Sono consentiti tutti gli attributi platform e alcuni tipi di attributi nativi, mentre gli attributi derivati sono disabilitati. Per costruzione, non è possibile dichiarare vincoli unique o index sugli attributi degli Enum, né impostarli required; l’unico attributo required è name, che è anche sempre object title. I campi dei letterali così strutturati possono essere compilati selezionando Class menu > Edit literal objects (a eccezione del name, che può essere cambiato rinominando il letterale sulla classe). Come per il name, nelle espressioni è possibile referenziare gli attributi del letterale con la sintassi <EnumClassName>[LITERAL_NAME].<AttributeName>.

Le uniche relazioni consentite con classi Enum sono associazioni unidirezionali, con l’Enum come target, con cardinalità Exactly one (1,1) o Zero or one (0,1). A livello di Application Schema è possibile imporre filtri di associazione o selection path sul ruolo che punta l’Enum. Sempre da questo schema è possibile scegliere la rappresentazione dell’Enum nelle form. La rappresentazione di default per nuovi Enum (con il solo attributo name) è un Dropdown menu con i nomi dei letterali come label; se vengono aggiunti nuovi attributi all’Enum, la rappresentazione cambia automaticamente in Single-row table.

Enum nell’applicazione generata

Gli Enum sono supportati in tutta l’applicazione generata:

• nel client web, gli Enum compaiono nelle form delle classi associate;
• in ambito Plugin, nello SPI generato è ora incluso un Java Enum per ogni classe Enum definita del modello. Inoltre, nel framework sono stati aggiunti nuovi servizi per ottenere i riferimenti ai literal object a partire dal name, oltre che dall’ID.
• in GraphQL è possibile specificare i letterali degli Enum nei servizi di scrittura per associare oggetti nuovi o esistenti alla classe Enum;

Enum e manutenzione evolutiva

In ambito di manutenzione evolutiva, il Database Checker e il Database Updater sono stati aggiornati per supportare tutti gli scenari di evoluzione che coinvolgono classi Enum.

Componenti interessati:, Designer (nuovo costrutto, icona nella palette e opzione nel Database menu, nuovo pannello per la modifica dei letterali), Database Checker (supporto scenari enum), Database Updater (supporto scenari enum), Engine Builder (QueryGenerator e RuntimeQueryGenerator, supporto alla nuova sintassi), Engine Framework (client web, SPI), API GraphQL

Risolta un’eccezione del Designer quando si cercava di evidenziare il path di un attributo query con espressione invalida o nulla, la cui invalidità era comunque segnalata correttamente con una issue.

Componenti interessati: Designer (Database schema)

Risolto un problema per cui, per ruoli rappresentati con la Editable, nel List layout Editor del ruolo non era possibile aggiungere nuove colonne relative ad altri ruoli della classe.

Componenti interessati: Designer (Application schema > List layout Editor)

In precedenza era possibile collegare classi Form alle normali classi usando associazioni bidirezionali, che venivano implicitamente convertite in unidirezionali. In alcuni scenari, questo portava alla mancata creazione delle tabelle relative alle classi Form.

Il comportamento è stato corretto nel Database Coder. Per eliminare ambiguità, nel Designer è stata reso più stringente il modo con cui ci si associa a classi Form: Ora non è più possibile creare relazioni bidirezionali tra classi normali e classi Form, o relazioni unidirezionali con classi Form come target; l’unica operazione consentita - e per cui il Designer non solleva errori - è creare un’associazione unidirezionale cliccando prima sulla classe Form e poi sull’altra classe.

Componenti interessati: DatabaseCoder, Designer (nuova issue)

Aggiornata la versione da OpenJDK 11.0.1 ad AdoptOpenJDK 11.0.8. È possibile verificare la versione Java della Dashboard da Menu > Help > About.

Per utenti base, l’aggiornamento avviene automaticamente col passaggio a Livebase 5.7. Per gli sviluppatori (utenti con parametro --withDomains) è necessario invece aggiornare manualmente la Dashboard scaricando un nuovo installer dal portale.

Il passaggio alla nuova versione Java migliora notevolmente la stabilità del Designer su tutti gli OS e risolve alcuni problemi noti:

• nel Designer, falliva l’operazione Export as XLSX eseguibile dal pannello degli LCP;
• nella Engine Library, le label degli LCP visualizzate a fianco dei modelli apparivano a metà.

Componenti interessati: Dashboard Client, Designer

Aggiunto il supporto al campo _clientId: ID nelle strutture dati <ClassName> dello schema generato. Il campo è un attributo speciale con l’unico scopo di fornire un ID temporaneo per referenziare oggetti che ancora non ne hanno uno effettivo perché non ancora persistiti nel database. Questo campo è opzionale: per essere utilizzato deve essere compilato dal client con un valore arbitrario (a es. hash, timestamp o numero casuale).

Grazie al _clientId, è ora possibile distinguere tra specifici oggetti Part quando si utilizzano servizi come preview e <RoleName>___associables per ruoli di composizione.

Contestualmente all’introduzione di questo campo, è stato rimosso il controllo sul modello che impediva la generazione dei servizi GraphQL in caso di modelli contenenti classi prive di attributi scrivibili; dato che ora tutte le strutture in input hanno almeno un attributo scrivibile, questo controllo è superfluo.

Componenti interessati: API GraphQL (schema builder)

Le classi Form erano già supportate in GraphQL ma erano trattate come classi comuni, pertanto venivano generati servizi inutilizzati. D’ora in poi, il builder genererà solamente servizi e tipi supportati dal Framework per questa tipologia di classe.

Le classi Form continuano a supportare i servizi GraphQL per i FormActionHandler introdotti nel rilascio precedente.

Componenti interessati: API GraphQL, Engine Builder, Engine Framework (modifiche a RuntimeQueryGenerator)

Il controllo sul tipo del valore di default di un attributo (impostabile da Application Schema con Attribute menu > Set default value > Constant) ora non tiene più conto del pattern di visualizzazione per i tipi di attributo con pattern - come Date, Time e Datetime.

Componenti interessati: Engine Builder

Con l’introduzione degli Enum, è stato sofisticato il modo in cui il framework inizializza gli attributi delle platform class (di cui l’Enum fa parte), risolvendo uno scenario di fallimento del build del modello in presenza di conditions su delle form che fanno uso di letterali.

Componenti interessati: Engine Builder

In alcuni scenari, l’aggiunta di un vincolo di cardinalità Exactly one (1,1) su un ruolo di una classe di un modello con dati pre-esistenti non veniva valutata correttamente dal Database Checker, che avrebbe dovuto segnalare una issue di livello high (i dati pre-esistenti non rispettano il vincolo di cardinalità).

Componenti interessati: Database Checker

Risolti dei problemi legati alla configurazione interna di alcuni servizi e descrittori dell’Hosting Servant e del Cloudlet Framework usati dal Database Checker per scenari di modifica che includono le classi Enum.

Componenti interessati: Hosting Servant, Cloudlet Framework (database)

È stata ripristinata una proprietà nel descrittore della Cloudlet affinché “sappia” di essere configurata con SSO.

Componenti interessati: Cloudlet Framework

Con l’introduzione degli Enum è stata sofisticata l’operazione per consentire di rilevare eventuali disallineamenti tra i record presenti sulle tabelle degli Enum nel database, e quelli definiti nel modello.

Componenti interessati: Hosting Servant

In precedenza, se si accedeva al database di una Cloudlet su cui erano presenti issue high per incompatibilità dei dati (ad esempio il dominio di un attributo), si risolveva manualmente la issue e in seguito si lanciava il comando Database issues > Force check database, le issue non venivano aggiornate.

Attualmente il problema è risolto lato server: il report viene correttamente aggiornato ed è possibile avviare la Dashboard, ma sulla Dashboard resta la notifica delle issue sull’icona del database. È comunque possibile refreshare manualmente la Dashboard per far sparire le issue.

Componenti interessati: Dashboard Servant

L’importazione di fogli Excel, in presenza di composizioni falliva per via di alcuni errori di CXF che impattavano i componenti Database Checker e Importer.

Componenti interessati: Database Checker, Database Importer (ExcelImporter), Dashboard Servant