While using std/db_sqlite I've noticed a warning about a circular dependency¹. That warning occurs even if open without any other code.
While searching for the Github issue (which I didn't find), I've found out that all db_* modules are likely to move out of std. This, along with that warning, made me to question the benefits of using the lib.
I'd be grateful for a more expert opinion on this — instead of relying on my own first impressions. Should one stick with it? Or it makes more sense to consider an alternative — since the lib is likely to become just one of other non-std options — and maybe even not the absolutely best one?
The main reason for me to pick it in the first place was compatibility and having fewer things to update. But without it being an std I kind of can't see a really solid reason to stick with it.
Does it make sense? And if it does — which of the alternatives are better for general use? nim-sqlite3-abi, sqliteral, tiny_sqlite? Or sticking with db_sqlite still makes more sense long-term?
———
¹ db_sqlite.nim(184, 1) Warning: Circular dependency detected. `codeReordering pragma may not be able to reorder some nodes properly [User]`
I too noticed the warning, it will be fixed.
I use the std modules all the time, for everything. But I know its limitations quite well and was around when the code was written. I'm as biased as possible. ;-)
When the modules move out of std I will need to update my .nimble dependencies but that's it and as a benefit I can use older versions of these modules with a new compiler.
Personally I use tiny_sqlite because it exposes types so nicely and is otherwise a very thin layer. I really like being close to the implementation when using SQL.
With that exception, I mostly use std without worrying about forward compatibility because it's nice to have fewer dependencies and because I really like Araq and the other core maintainers touch.
Is there any progress on this problem.
Should I take tiny_sqlite
thank