Suonala ancora, Sam

Negli ultimi giorni ho preso una decisione cardinale: riscrivo l'engine di Hyppocampus.
Da notare che preciso il fatto di voler riscrivere la parte di risoluzione, ovvero il pezzo di codice che riconduce dalla rappresentazione interna della query al result set, non il parser (che sarebbe quello che porta dalla query in forma testuale alla rappresentazione interna): l'obiettivo e' rivedere pesantemente anche quello, ma l'opera non e' realizzabile se prima non si formalizzano meglio gli internals con cui i dati vengono gestiti.
Questa decisione e' presa alla luce del fatto che, allo stato corrente, tale porzione (che del resto comprende quasi la meta' dell'intera applicazione) non e' stata preventivamente studiata per essere espansa e supportare nuove funzionalita', ed oggi, che vorrei introdurre l'indispensabile trattamento di selezioni multiple e la clausola ORDER BY nelle query avanzate al filesystem, dovrei aggiungere parametri su parametri alle gia' sufficientemente incomprensibili routines interne per ottenere il risultato sperato.
Indi: apro un nuovo file, recupero il recuperabile (il parser testuale, appunto, e qualche algoritmo sparso), formalizzo tutti i dati in strutture che innalzino in grado di astrazione delle informazioni manipolate e ne rendano piu' comprensibile l'utilizzo, e ci lavoro su. Per questo, dubito che prima di agosto si vedra' una nuova release del filesystem correntemente "piu' relazionale" della piazza ;-) .

Profitto dell'argomento per esprimere un inciso per tutti coloro che piu' volte mi han chiesto perche' non uso una base relazionale esistente per mantenere i dati e persevero nel volerne scrivere una da me: il punto sta nel fatto che, di per loro, un database ed un filesystem sono assai diversi, e tradurre la sintassi di accesso ad uno nella sintassi dell'altro e' un lavoro persino piu' complesso che non la riscrittura di uno dei due componenti in tale ottica. Volendo creare una tabella di database secondo l'attuale struttura logica di Hyppocampus essa dovrebbe avere 2^64 campi, uno per ogni metadato possibile (essendo mappati su 64 bits), e la maggior parte della tabella sarebbe comunque vuota; volendo dividere la tabella secondo la struttura "una riga per ogni metadato" ci si imbatterebbe nella gestione della varieta' di possibili tipi di dato assegnabili a suddetti metadati (al momento: int, short, long long, [che possono anche essere unsigned], stringa, stringa UTF-8, boolean, float, char, struct, per non parlare degli altri tipi astratti...) e con un'elevazione nel grado di complessita' delle query richieste per accedere al filesystem; volendo adottare quest'ultimo approccio ma mascherando l'accesso al database secondo lo schema proposto nella prima opzione, occorrerebbe stare a tradurre ogni query da un formato all'altro, compito non banale...
Poi ci sono tutte le problematiche relative alle prestazioni (per quanto un DB general purpose possa essere veloce, una base dati appositamente studiata per compiere certi tipi di operazione se ben implementata diventa ben piu' ottimizzata e piu' rapida), alle limitazioni (i campi di un DB devono essere sempre dimensionati a priori, mentre uno degli obiettivi in Hyppocampus e' quello di permettere grandezze arbitrarie per i valori assegnati) eccetera...

Un lungo lavoro di progettazione mi attende: questa volta, tanto per cambiare ( ;-) ), vorrei studiarmi bene la situazione prima di iniziare a stendere il codice...
Stay tuned ;-)