<@U25U0KPFT> <@U0BDMQTHS> Thanks for your recommen...

# tornadofx

[elexx]

@carlw @mikehearn Thanks for your recommendations!
@amanda.hinchman-dominguez Actually I already began implementing a "backend" using TornadoFX JSON capabilities. My approach was quite simple: 1 JSON file per collection of items. But I'm not sure this will scale well when loading larger collections.
I'm working on a budgeting software for personal use - so I need to read and store files like for example a word processor does. But I'm struggling with the format. I really would like some sort of basic SQL (nothing super fancy, only things like querying all transactions with a given account or map&fold a collection of transaction to a final balance). However I don't think a H2/HSQLDB + Hibernate setup is really the thing I want. Some middle ground would be nice. Not worrying about how/when the data is actually stored on disk and having a simple querying interface.

[anidotnet]

You can have a look at nitrite - https://github.com/dizitart/nitrite-database for kotlin binding see potassium-nitrite.

Disclaimer: I am the author 😀

[elexx]

That's what I'm currently using 😉 https://github.com/elexx/spaarpot But don't expect to much from the repo, it's still work in progress

[elexx]

However, I'd really appreciate feedback on what can be improved or done more idiomatic! Esp when it comes to how to connect the DB with Tornado. Going for POKOs (data classes) or using fx (property based) models and serializing on my own using Mappable or something totally different?! 🙂

[anidotnet]

I just had a quick look on your project.

First thing I'll say is is to refactored the db handling code out of Controller class.

Second if you are using shutdown event to close the db then you should disable jvm shutdown hook of nitrite in the builder. It is available in 3.0.1.

Lastly if you want to use tornado fx property, you would be better off with using Mappable. Default jackson serialization fails to serialize tornadofx properties.