Posts

ActiveRecord adapter improvements

Ruby on Rails continues to be a lively and thriving framework. Unfortunately, when it comes to the database adapters, a vast majority of the attention and effort has been focused on the MySQL and PosgreSQL adapters. SQLite supports a large percentage of the database features that Rails has added support for in the recent past. So, today I am starting to do my part to make the developer experience of using Rails with SQLite as seamless and powerful as possible. Maybe you’ll join me?

Local snapshots

Today we consider how SQLite can enhance working with our database in our Ruby on Rails applications. The the database is simply a file, snapshots and clones are both simple and powerful.

Array columns

One of the reasons people hesitate to use SQLite in their Ruby on Rails applications, in my opinion, is a fear that they will miss certain features they are accustomed to from PostgeSQL or MySQL. As discussed in an earlier post, we can load SQLite extensions into our Rails applications to enhance the functionality of SQLite. Moreover, today I want to show you that it is possible to build on top of SQLite’s primitives to provide matching behavior for one of my favorite features of Postgres—array columns.

Optimizing compilation

This is the next in a collection of posts on how to enhance SQLite in order to power up our Ruby on Rails applications. In this post, we dig into how to tune SQLite at compile-time to better support production usage in a web application. This is a close companion to a previous post on optimizing the run-time configuration of a SQLite database.

Setting up Litestream

This is the next in a collection of posts where I want to highlight ways we can use SQLite as the database engine for our Rails applications without giving up key features or power. In this post, I want to discuss one of the most often discussed disadvantages of SQLite—disaster recovery—and how to address it.

Loading extensions

Once again we are enhancing our Ruby on Rails applications to power up SQLite. In this post, we dig into how to load extensions into our SQLite database.

Linked headings in your BridgetownRB site

BridgetownRB is a powerful and flexible “progressive site generator” written in Ruby. I use it to publish this blog. One feature that I wanted to support with my blog is having headings that provide a quick anchor link to that section of the page. In this post, I want to walk you through the simple steps to add this feature to a Bridgetown site.

Fine-tuning your database

This is the next in a collection of posts where I want to highlight ways we can enhance our Ruby on Rails applications to take advantage of and empower using SQLite as the database engine for our Rails applications. In this post, we dig into how to tune the SQLite configuration to better support production usage in a web application.

Branch-specific databases

This is the first in a collection of posts where I want to highlight ways we can enhance our Ruby on Rails applications. Specifically, in this first series, I want to dig into the ways that we can take advantage of and empower using SQLite as the database engine for our Rails applications. In this inaugural post, let’s dig into how using SQLite as our database engine opens up powerful new possibilities for our local development workflow; specifically, allowing us to have and use branch-specific databases.

Generating Hex-ULIDs in Ruby

In the previous post, we explored how to generate a base16-encoded ULIDs with only native SQLite functions. In the end, we built an expression that will generate hex-ULIDs for us:

SELECT PRINTF('%012X', CAST(ROUND((JULIANDAY('now') - 2440587.5)*86400000) AS INTEGER)) | HEX(RANDOMBLOB(10)) AS qulid;
SELECT PRINTF('%012X', CAST(ROUND((JULIANDAY('now') - 2440587.5)*86400000) AS INTEGER)) | HEX(RANDOMBLOB(10)) AS qulid;

This expression will return a 32 character string like 0184E14B9D33DF0EA40E00D20FC31406, which encodes a 48 bit timestamp and an 80 bit random portion, producing a 128 bit blob just like ULIDs and UUIDs. The string is composed of an 12 character base16-encoded timestamp and a 20 character random portion.

But what if we need to generate a hex-ULID in Ruby?