2014-03-24 10:53 GMT+01:00 <[email protected]>: > 2) la logica delle API di libsqlite3 non somiglia minimanente a > quanto si trova normalmente nelle librerie client p.es. di MySQL > o di PostgreSQL; ma non dovrebbe stupire piu' di tanto, visto > che non e' un DBMS client-server. > corollario: pretendere di incapsulare SQLite entro le maglie > rigide e prefissate di schemi astratti concepiti per i DBMS > client-server (JDBC, ODBC e compagnia bella) non e' il modo > piu' "smart" per utilizzare SQLite. > si aggiungono sicuramente ulteriori strati intermedi non > strettamente indispensabili, e si rischia cosi' di > introdurre inopinate cause di fragilita' in un'architettura > che sarebbe invece di suo assolutamente solida e robusta > (se utilizzata nel verso giusto per cui e' stata progettata, > senza costringerla a controrsioni innaturali). >
Si, di questo si era consapevoli, e l'opzione di riscrivere completamente lo store per usare l'API di sqlite/spatialite direttamente è stata presa in considerazione. Solo che... è un sacco di lavoro. Gli store JDBC condividono una notevole quantità di codice, delegando le differenze fra un database e l'altro a un paio di classi, il dialetto e l'sql encoder, partendo da zero e usando un approcccio diverso da JDBC tutto questo corpo di codice andrebbe riscritto per usare le API dirette di sqlite. Senza considerare gli oltre 300 test automatici già disponibili per gli store JDBC, che di nuovo andrebbero riscritti per uno store che non sia basato su JDBCDataStore. Infine, ci sarebe il costo di manutenzione a lungo termine, una volta preparato questo nuovo codice, chi lo mantiene a lungo termine? Gli store JDBC hanno di bello che la condivisione di molto codice rende lo sforzo di manutenzione piuttosto contenuto, e quando si implementa una miglioria per una della basi dati spaziali, la si trova spesso già pronta, o implementabile con piccolo sforzo, anche per le altre. Ciao Andrea -- == Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it -------------------------------------------------------
_______________________________________________ [email protected] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 666 iscritti al 22.7.2013
