Re: [geogig-dev] mapdb storage module prototype

[<Schmidt.Sebastian2@xxxxxx>]

Hi Gabriel,

it's a good thing to have this discussion on the mailing list.

When starting on this feature, in the first place I was curious how much 
time it would take to write a new storage backend at all, and thanks to 
the pluggable architecture and test classes written against the 
interfaces it was surprisingly easy, which is good news in any case.

In the meantime I'm able to import a (small) dataset of about 20.000 
polygons and serving it back via the geoserver-geogig extension with 
this prototype, running both on win64/oracle jdk and linux (Ubuntu)/openjdk 
machines. In the 2.0  series of mapbd they even implemented a Write Ahead 
Log for times of JVM Crashes that are promised to be played back on recovery.

Currently I wouldn't suggest mapdb as default storage backend either. 
The fact that even code taken from the examples fails doesn't point in 
the direction of 'rock solid' software as a database should be. On the 
other hand: pulling dependencies to non-java-libraries into a pure java 
project is not the most elegant solution either. So having an 
alternative for use cases like mobile devices etc. could be helpful.

SQLite points more in the direction of C++ coders, where cool things 
like Foreign Data Wrappers from PostgreSQL or GDAL/QGIS come into play, 
wich is great for interoperability - I guess the first QGIS Plugin that 
is able to read and write into GeoGIG repos directly without the need of 
going through a JVM would get a lot of applause from the interested 
audience.

For the time being, let's say until the end of this year, I'll do the 
following:
* watching mapdb, waiting for a 2.0 release.
* syncing from time to time in order not to fall too far behind the 
master branch
* Keeping it on my private fork. If anyone is interested in going on - 
feel free.

If you would need a little testing of a sqlite storage module, for 
example on windows machines, feel free to ask for help on that. I could 
stress it with one of our "medium size" datasets (raniging from about 
600.000 parcels up to about 10 million point features).

Kind regards,
Sebastian