Has sqlite3 ever been considered as an addition to vendors?
1 Like
They will never be added because as soon as we add one set of database bindings, people will want their favourite one, of which there are dozens, if not hundreds, of different SQL-like databases out there.
It’s not something I believe is a good idea for vendor.
3 Likes
I am not sure there are any viable alternatives to sqlite. Its pretty much the standard inprocess embeddable database and imo it makes a lot of sense in supporting it. Also sqlite is just one C file so its pretty straightforward to support.
There are a lot popular sql databases but none of them are embeddable or in process afaik.
1 Like
one thing that maybe would fit in vendor might be the sql api specification that a database driver would need to conform to expose sql capabilities. Making sure to handle parametrized queries and such.
Then sqlite would be one of the drivers that lives in the wider odin ecosystem.
I’ve never been sure about those because it seems like it is abstracting something which shouldn’t be. Do you need a generic SQL interface when you know exactly what database your project will be using? It’s not like you can trivially swap between different databases and expect them to work without changing loads of things.
1 Like
it is useful if you can trivially change between a local test (sqlite) database and the real database in production with no code changes
1 Like
Sure, but maybe this is me being dumb but why isn’t the local database the same kind as the production one?
I think a goal of an interface that makes multiple database vendors compatible is both out-of-scope [for this thread], and unwise. Let’s keep the discussion to SQLite only.
I do agree with @waqar144; SQLite is in a league of its own, quite different from other databases. It (and its format) are used in many places, and for many purposes, not just back-end services like most other database engines. It’s also often [used as] a configuration or serialization format as well as just a database. Not to mention that it is extremely mature and stable, too.
I think a goal of an interface that makes multiple database vendors compatible is both out-of-scope [for this thread] and unwise
+1
SQLite might be quite different to many other databases but that slippery slope is still there. As soon as I allow for just one, I will be inundated with requests for more, and saying “no” won’t be enough.
Ok, but in a way you can make the same argument for a lot of stuff in the vendor directory atm. Its not a big deal though, most things will have to live outside vendor. The reason I thougt it would be a good candidate for vendor was because its a very commonly used lib and would make the vendor a tiny bit more generic which currently is more or less just graphics stuff.
3 Likes
Coming probably a bit late to this discussion.
In golang there is an abstracted sql interface in the standard library and every non-helloworld project eventually ends up not using it as it is quite limiting. Bill is right here - this is not something that should be abstracted. All projects pick a database to specialize on eventually because supporting multiple different databases is a maintenance pain that nobody wants to do.
That being said I think sqlite deserves an exception here. It is extremely useful and it is ubiquitous. Don’t treat it as a one of many possible SQL databases in vendor. Treat it as one of a kind thing. Example: python has sqlite built into the language while no other databases have same level of treatment.
5 Likes