Meta comment: This is a domain under my countries TLD (Slovakia) and it is one of the handful of words that are a word with the TLD in my language (and coincidentally) also in English. Every now and then, I will check on the domains with a retrograde dictionary for domains that have this property and root of this particular domain had a roundcube email server on it (can be checked on archive.org). After further check…
SQLite is all you need for durable workflows
151–160 of 413 posts
Re: SQLite is all you need for durable workflows
#152Earlier quoted context omitted.
Could you give an example of a case where you'd use SQLite instead of jq or grep through Markdown?
> an example of a case where you'd use SQLite instead of jq or grep through Markdown? Usually we end up writing a script to incrementally refresh a data-set I'm analyzing (or have someone send me a copy after they pull it). I've been using sqlite for anything which needs an UPDATE - modifying a row deep inside the data-set with jsonl is a pain. My github is full of java programs which update sqlite3 files with thread…
Re: SQLite is all you need for durable workflows
#153Earlier quoted context omitted.
Well if you run a tiny single-threaded app then SQLite is a nice simplification over spinning up a separate machine for Postgres.
Or you can run postgres on the same machine as the application, which lets you much more easily migrate if the time comes when you need to scale to multiple application servers. There's a world between "local file" and "network DB server", running a DB server locally has lots of benefits from being able to easily query from outside if needed to forcing you to consider concurrency without the latency overhead of a net…
Re: SQLite is all you need for durable workflows
#154I don't understand this obsession with SQLite for real, production apps. SQLite is an embedded database, completely unsuitable for managing concurrency. This is what database _servers_ are for, e.g., Postgres, MySQL, etc. Their entire job is to allow you to modify data from multiple processes, on different machines, at the same time. This is a foundational principle of computer science. It seems to me that the "SQLit…
I absolutely 100% do not understand it either. At all. Every time I try to over the last year or two I come away with the conclusion its something that sounds cool (to me too!) but is guaranteed to cause more problems than more obvious solutions. That being said I'd kill for someone who used it and benefited to explain it to me in a practical sense. (specifically where syncing is involved, and syncing a subset of the…
Re: SQLite is all you need for durable workflows
#155Earlier quoted context omitted.
GP calls out concurrency as a weakness of SQLite. Most of the examples here don't experience the same load even a moderately sized web service experience day to day. And no, being a part of the python standard library doesn't means it is being used by the average python user. These days I'd say at least half of them are just there for machine learning.
SQLite is good for read-concurrency, not great for write-concurrency.
Re: SQLite is all you need for durable workflows
#156Re: SQLite is all you need for durable workflows
#157Earlier quoted context omitted.
You can use strict tables: https://sqlite.org/stricttables.html
This could enforce dates are strings. They wanted to enforce dates are dates I thought.
create table events (
id integer primary key,
name text not null,
event_date text not null check (
-- YYYY-MM-DD
event_date glob '[0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9]'
and date(event_date) is not null
and date(event_date) = event_date
)
);
In Python that raises this error if the date is invalid: sqlite3.IntegrityError: CHECK constraint failed:
event_date glob '[0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9]'Re: SQLite is all you need for durable workflows
#158I started setting up my workflows using Temporal. It deploys as relatively light weight local app. For an isolated local installation it uses SQLite. It makes the process of dealing with API retries and organizing workflows and tasks really simple. I recommend giving it a try. It is, philosophically, exactly what this article is suggesting, but it adds an incredibly rich and flexible interface for agents to work with…
Word on HN is that you're either paying more money than you expected for temporal's managed solution or taking on substantial ops burden ultimately running their very heavy system yourself. I wouldn't know, I've not done either, but I'd like to learn more from your or other's experience.
Re: SQLite is all you need for durable workflows
#159Earlier quoted context omitted.
Are logs all you need for durable workflows? I'm confused here. How'd persist and query nested or related data over logs? By logs I assume you mean something like elasticsearch or meilisearch?
I assume they meant a log like a WAL. A WAL should be (quite literally?) all you need for durable workflows. A distributed WAL (to survive a machine death) would also probably be something I'd want, and … something I'm not sure you're getting directly from SQLite.
Re: SQLite is all you need for durable workflows
#160Earlier quoted context omitted.
I guess I need to dive deeper into this as I do not understand the implications you gave me, but I appreciate the attempt. Generally I understand why concurrency is good in many cases, I just dont get why its important for database stuff too. Edit: thanks for clarifying in the edit, makes a lot more sense.
Imagine if every tweet had to go through a one-at-a-time queue before being persisted. There's about 6000 tweets per second, so you would have to be able to save them at <0.17ms per tweet or else you would become backlogged. If you are getting backlogged, you have to buffer those incoming tweets somewhere until they can be writted, and eventually that buffer gets full and you start losing tweets.