persistence layer

[helio-clementino]

I imagine you have already thought about using a relational/document database instead of json files. Could you share your thoughts?

[hguy]

Hi @helio-clementino , Yes i though about using SQLite/Firebird. There's pros and cons about it.

Pros

• Better Search architecture
• All Vault data is always available and unified at all time (no progressive loading when setting "Preload All" is Disabled) that make the tool smarter and open few features.
• Performance (relative to vault count)

Cons

• At launch
  • Automatic migration code for DB Schema
  • If you don't backup your previous install, you can't rollback
  • Automatic migration code from file to DB for all format (Bin, JSON)
  • Integrity check handling (vault name collision, item position collision)
• Users tend to share vault file and don't want to share all their vaults at once
  • Need to have a Import/Export vault wizard with an intermediate file format (current JSon could do the trick) for vault sharing
• Automatic Real Time Sync code between "Game Files" -> "Vault DB".
• A good amount of refacto
• Increase the technical entry level in the project

Conclusion

It's nice feature and there is real benefits but it need a lot of tests to be useful and reliable and most users won't need it or notice it. At that point, it's more of a splinter in our engineer brain than a real user need. If the underlying layers of code base were shared with a wider project like a webapi and/or webapp, these modifications could be justified for technical/performance reasons. That's my thoughts about it.

[helio-clementino]

Thanks for replying. Indeed it can take a considerable effort to make such changes and they may not be noticeable by most of the users. Keep it up with such great work!