veganism.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
Veganism Social is a welcoming space on the internet for vegans to connect and engage with the broader decentralized social media community.

Administered by:

Server stats:

214
active users

#sqlite

11 posts9 participants2 posts today

Hey all, I wrote a #PHP #SQLite #OpenSource forum called #Threadbare - github.com/Moult/threadbare

If your community is mailing list scale (i.e. not huge multilingual multicategory nested threads) check it out. If you're looking for an alternative to works-only-with-JS needs-containerisation logs-everything and want something minimal with performance near to a static site, it might be for you. Would love feedback and testing and security advice!

See community-test.osarch.org/ for demo.

Finally came up with a project to learn #Rust with. Not moving particularly fast, but it's making me spend a lot of time considering the implementation of data structures with ownership and lifetimes in mind.

I've been away from system-level programming for a while and last time I did any it was #C++ which is its own kind of pain.

Working on building up structures backed by a #sqlite #database as well, so getting #SQL practice also.

🌘 沙丁魚罐頭:使用 Rails 實現 SQLite 多租戶架構
➤ 克服 ActiveRecord 的限制,實現高效能多租戶架構
blog.julik.nl/2025/04/a-can-of
本文探討了在 Rails 應用程式中實作「每個租戶一個資料庫」架構的挑戰。作者分享了過去在維護一個使用此架構的應用程式時遇到的問題,並指出現有的多租戶 gem (如 Apartment) 也存在類似的線程安全問題。文章深入探討了 ActiveRecord 連線管理機制,以及 Rails 如何使看似簡單的任務變得複雜,並提供了一個可行的解決方案:一個中間件,能有效處理多租戶環境下的資料庫連線。作者強調了使用 SQLite 作為小型專案的優勢,例如易於配置、備份及除錯,並指出此架構能有效限制資料庫規模,降低複雜性。
+ 這篇文章深入淺出地分析了 Rails 多租戶架構的難點,對於正在考慮類似方案的開發者來說,非常有參考價值。
+ 作者的經驗分享很實用,提供的中間件解決方案讓我看到了希望,可以嘗試應用在我
#Rails #SQLite #多租戶 #資料庫架構

Julik Tarkhanov · A Can of Shardines: SQLite Multitenancy With RailsThere is a pattern I am very fond of - “one database per tenant” in web applications with multiple, isolated users. Recently, I needed to fix an application I had for a long time where this database-per-tenant multitenancy utterly broke down, because I was doing connection management wrong. Which begat the question: how do you even approach doing it right? And it turns out I was not alone in this. The most popular gem for multitenancy - Apartment - which I have even used in my failed startup back in the day - has the issue too. The culprit of does not handle multithreading very well is actually deeper. Way deeper. Doing runtime-defined multiple databases with Rails has only recently become less haphazard, and there are no tools either via gems or built-in that facilitate these flows. It has also accrued a ton of complexity, and also changes with every major Rails revision. TL;DR If you need to do database-per-tenant multitenancy with Rails or ActiveRecord right now - grab the middleware from this gist and move on. If you are curious about the genesis of this solution, strap in - we are going on a tour of a sizeable problem, and of an API of stature - the ActiveRecord connection management. Read on and join me on the ride! Many thanks to Kir Shatrov and Stephen Margheim for their help in this.
Continued thread

one thing i certainly love about side projects is that it gets us out of the daily perpetual work rabbit whole with endless pre-defined constraints!

for this homelab/ #iott sensor stuff i finally got to play with #sqlite and i’m really loving it. since everything is also running locally (and i finally made sqlite indexes work) this home sensor page for my e-ink display loads *SO FAST* with just a couple of ms 💛

If this message made it to you, it means the migration from #GoToSocial 0.18.3 to 0.19.0 went ok. The whole upgrade process, database migration stuff included, took only a couple of minutes; the #SQlite database is 1GB large. Of course, it runs on #NetBSD; using the official build.

Replied to argv minus one

@argv_minus_one
If it is actually written, yes. But #SQLite might detect there is no actual change and not declare the page dirty. And even if it is declared dirty, the row size will not change, so the B-Tree structure will be stable.
The page has to be read anyway, so both the disk cache and the SQLite page cache are primed. Except for hi-speed, hi-volume applications, I would not worry in advance. Premature optimization is the root of all evil.

I am disappointed to find that, with #SQLite, an INSERT statement with both ON CONFLICT DO NOTHING and RETURNING clauses won't return anything if there is a conflict.

I have a table that's basically just for interning frequently-used strings. It has a numeric ID column and a unique text column, and I want to get the ID for a given string, inserting if necessary.

With this RETURNING behavior, that has to be done in two steps, not one. 😔