Hi Sebastian,
I'm very pleased that you feel comfortable doing geogig development and trying things out. Way to go!
WRT MapDB, I'm still very hesitant to propose it as the replacement for the default storage backend.
I did use it last year, on a couple geogig experimental branches. Not for an objectdb implementation though, but similar, for a temporary Node index when importing very large datasets (in the order of whole America osm exports). I decided against it and implemented FileNodeIndex, much less ambitious and to the point of my requirements.
The rationale for my hesitation is something like:
- it is a one-man project (nothing essentially wrong with that, but...)
- off-heap memory usage (i.e. MappedByteBuffer) works like a gem on Linux/Unix'es but I'm afraid it can be quite problematic on Windows.
- performance seemed to degrade quite "ungracefully" anyways
- at least at that time, it was good enough for a non huge node index, but lacked the persistence guarantees a "proper" backend storage would require for storing the repo's objects. LMN was even making "switch-the-plug" kind of consistency testing on the bdb je backend to ensure repo consistency under catastrophe.
Now, _all_ of that is off the top of my head, and I'm sure the mapdb developers would argue furiously. But the bottom line for me is we rather go with something which reliability can be trusted by being established and well known/used by a wider audience, and ideally that can be read by other software/programming languages.
That said, SQLite is quite a pain in the neck too, as far as I can tell, but if I/we get the usage pattern right it might be that "consolidated" backend we need.
Does that make sense?
Cheers,
Gabriel