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