| Re: [geogig-dev] mapdb storage module prototype |
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
_______________________________________________
geogig-dev mailing list
geogig-dev@xxxxxxxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
http://www.locationtech.org/mailman/listinfo/geogig-dev
Gabriel Roldán
Software Developer | Boundless
groldan@xxxxxxxxxxxxxxxx
@boundlessgeo