Posts tagged: database

Absolutely incredible what Preston is doing with his time. What a life changing experience this must be for him. Good job to Turso for making this happen. We are going to end up with very feature rich file based databases out of this that the whole world will benefit from.

I really like how well the local dev is setup to run off of production data here. I’ll use this as a reminder that I need to set up lite stream on a few of my projects that it’s missing from and include a nice sync prod data Posts tagged: justfile recipe.

Litestreams interface always throws me for a loop. It works fantastic, but the global config stored in /etc and some of the commands break my brain. It’s not you it’s me.

Using real data when you can is goated. Fake data is so often a perfect example of what someone thinks the backend should look like and does not include things that users actually do, running pipelines for days, or setting titles to paragraphs worth of text. Obviously this is not possible everywhere and the more sensitive your data the harder that process becomes.

I’ve never tried generated columns, but it is something that I’m interested in. It is nice to have things computed and in the database if you ever need to query on them. My brain is now churning with possibilities and quesions, does this work with Alembic? How does this compare to views?

This talk about live store really made me think about database transactions in a new way. They are talking about live-store, and the complexity of distributed applications like a notes app with the ability to go offline and continue working. The complexity of resyncing each instance is not simple, conflict resolution accross all the possible installs that may or may not even be online is a really hard problem. They go deep on discussing an event driven paradigm that is driven off of a log of events and how this changes how we deal with databases. Using the event log as the source of truth we can do things like forget about database migrations, we can replay all of the events onto a new database. Its very interesting to rethink in terms of a log system that speaks in terms of understandable events (not table operations) as the source of truth for an application.

SQLModel models ship with an is_, and is_not that you can use to compare to None without pesky linters complaining.

This comment summed it up quite well.

I believe this is concerned entirely with SQLAlchemy, not with SQLModel, and has to do with the required semantics to construct a BinaryExpression object. Hero.age == None evaluates to a BinaryExpression object which is eventually used to construct the SQL query that the SQLAlchemy engine issues to your DBMS. Hero.age is None evaluates to False immediately, and not a BinaryExpression, which short-circuits the query no matter the value of age in a row. From a cursory search, it does not seem that the is operator can be overridden in Python. This could help explain why the only possibility is by using the == operator, which can be overridden.

so rather than using Team.heros == None we can use Team.seros.is_(None) which checks for itentity not equality.

Aaron Francis is a database master, pumped for thsi dude and all that he is able to accomplish.

Simon shared a really cool new utility tool for sqlite ispired by rsync. It checks hashes of each sqlite page and syncs pages. So if nothing in the database has changed it will only require 0.5% the bandwidth as a copy would.

Sqlite is getting rust extensions now, and datetimes make it totally worth if if they work well and and fast, two things that don’t always go together in datetime libraries

I learned about the sqlite_master table from this stack overflow answer. This helps make a lot of sense to how sqlite works. The master table contains all the sqlite objects and the sql to create them.

The .tables, and .schema “helper” functions don’t look into ATTACHed databases: they just query the SQLITE_MASTER table for the “main” database. Consequently, if you used

Another interesting option for slow count queries in sqlite.

If you haven’t DELETEd any records, doing:

Very interesting article by Sylvain, suggested by Simon Willison.

Definitely some things that I want to come back and try later on.

Here is the TLDR of the whole post

PRAGMA journal_mode = WAL; PRAGMA busy_timeout = 5000; PRAGMA synchronous = NORMAL; PRAGMA cache_size = 1000000000; PRAGMA foreign_keys = true; PRAGMA temp_store = memory;

This is interesting, and something I need to consider. I definitely have an application with slow count queries. I am not sure how to make it better as its not a full count(*) so a count table doesn’t work, nor does counting by index.

...

![[None]]

![[None]]

First I need to fetch my thoughts from the api, and put it in a local sqlite database using sqlite-utils.

fthoughts () { # fetch thoughts curl 'https://thoughts.waylonwalker.com/posts/waylonwalker/?page_size=9999999999' | sqlite-utils insert ~/.config/thoughts/database2.db post --pk=id --alter --ignore - }

Now that I have my posts in a local sqlite database I can use sqlite-utils to enable full text search and populate the full text search on the post table using the title message and tags columns as search.

sthoughts () { # search thoughts # sqlite-utils enable-fts ~/.config/thoughts/database2.db post title message tags # sqlite-utils populate-fts ~/.config/thoughts/database2.db post title message tags sqlite-utils search ~/.config/thoughts/database2.db post "$*" | ~/git/thoughts/format_thought.py | bat --style=plain --color=always --language=markdown } alias st=sthoughts

Now I am ready to search my thoughts, which is a tiny blog format that I created mostly for leaving my own personal comment on web pages, so most of them have a link to some other online content, and their title is based...

Great example from Anthony showing how easy it is to practice building database orm models and playing with them in a repl. This is good practice even if you are in a big code base to be able to test and learn in a simplified code base that does not have a mountain of other code around atuh, permissions, security, and other complex things that come into real production code bases that might make it hard to focus on what you are trying to do.

Today I came across some sqlalchemy models that created some relationships, some used backref some used back_populates. I was stumped why, I had never came accross backref before and I felt skill issues sinking in.

https://docs.sqlalchemy.org/en/14/orm/backref.html

As stated in the sqlalchemy docs, backref is a legacy feature. Its shorthand to creating relationships between parent and child, but only adding it to the parent. While this is simpler it introduces some invisible magic.

Today I was running some sqlmodel queries through the sqlalchemy orm. Admittedly I’ve not done enough orm queries before, and I’ve done quite a bit of raw sql. I was trying to get objects from two separate models that had relationships setup.

session.query(User, Images).where(User.id == 3).all()

It is incredibly slow, and gives me the following warning.

SELECT statement has a cartesian product between FROM element(s)

What I learned from the SQLModel docs is that you should give it a join to correct this and go much faster.

Ben Johnson was on the Changelog a few years back covering his work on litestream, and talks about why he chose to go open source, but not open contribution.

You should have a good reason to move off of sqlite.

Very inspiring talk, TLDR, you probably don’t need a database server. sqlite will probably be faster, simpler to maintain, and simpler to test your application.

`litestream` is a sick cli tool for steaming replicas of sqlite. It automatically does daily snapshots, and streams all of the writes to the replica live.

install #

Install is fast using installer, no compilation, just copy the binary and run.

As applications scale to the edge, to put compute as close to the user as possible, database queries back to the master node get slower and slower. Enter sqlite replication, put the database wtih the application code and replicate from master.