3 ms·
SQLite not supporting "stored procedures" is a deal-breaker for me. The idea for stored procs is not to "put the process as close to the data" but simply that w
by ak39 3y ago
SQLite not supporting "stored procedures" is a deal-breaker for me. The idea for stored procs is not to "put the process as close to the data" but simply that we have a single place for language-agnostic encapsulation of data procedures.
- chungy 3y agoSQLite is an in-process database. If you need language-agnostic encapsulation of data procedures, SQLite is not for you. I would suggest you consider PostgreSQL.
- ketralnis 3y agoI don't think I've ever needed language-agnostic procedures in a project where sqlite is also a fit. I like them both but at different times. I'd love to hear your use case though. Do you have microservices in different languages running on the same machine that share a db file? Or maybe a web + command line interface? Sqlite's internals actually could support something like this: it has a bytecode engine https://www.sqlite.org/opcode.html https://www.sqlite.org/opcode.html that's more oriented around executing query plans and it's missing some pieces (e.g. it has no stack, only registers) but much of the machinery is there to expand it to stored procedures
- pstuart 3y agoWhat language(s) would the stored procedures be, and how would that look in keeping with the ethos of the project? Their reasoning for not doing this is not unreasonable, but it certainly would be cool if such functionality existed.
- bob1029 3y agoSQLite supports the best version of "stored procedures", IMO: https://www.sqlite.org/appfunc.html https://www.sqlite.org/appfunc.html
- hahn-kev 3y agoBut man the maintenance and debug nightmare never seems worth it for that tradeoff. Not to mention vendor lockin
- chasil 3y agoThe language for triggers in SQLite appears to be a fragment of SQL/PSM and Oracle PL/SQL. Perhaps this will grow into a more thorough implementation.