Well, since this handle is a Reference to a NIF resource then I’m weary of restarting. I prefer having a runtime-updatable configuration as you called it and it just takes effect for all work done under the NIF handle after the config is modified. As per my two above examples: modifying the execution timeout or batch size count are quite okay options to modify as you go. They are not some mythical gospels so big and powerful that the GenServer must absolutely be restarted to cope with their change. If I am missing something here, do let me know though!
The library definitely does not need GenServers per se. It’s just that I view them as a very sensible default way to organize your work in the case of e.g. your application uses 15 sqlite databases. And each GenServer will hold (a) configuration and (b) the NIF resource Reference. In other words, the entire vanilla data structure that you otherwise have to pass around.
If we were working together on such a PR, would you press your point that optional OTP primitives in these cases shouldn’t be a part of a library? I am curious. I view automatic organisation of sqlite database handles via GenServers as a pretty handy mechanism, it’s really minimal and is strictly opt-in. (I agree that just carrying a structure around is the best default vanilla approach and that’s what I am going to do first. The OTP stuff is going to be a small, hopefully useful, extra.)
