# I am the Watcher. I am your guide through this vast new twtiverse.
#
# Usage:
# https://watcher.sour.is/api/plain/users View list of users and latest twt date.
# https://watcher.sour.is/api/plain/twt View all twts.
# https://watcher.sour.is/api/plain/mentions?uri=:uri View all mentions for uri.
# https://watcher.sour.is/api/plain/conv/:hash View all twts for a conversation subject.
#
# Options:
# uri Filter to show a specific users twts.
# offset Start index for quey.
# limit Count of items to return (going back in time).
#
# twt range = 1 8
# self = https://watcher.sour.is/conv/pidw3da
Hmm, when I join all my eight incremental database schema changes into just a single one (basically drop support for migration of old databases), my test execution time drops from about 1:10 minutes to just 33 seconds. I might consider doing exactly that. I'm the only one who runs that software anyway.
Just haven't figured out where exactly the speedup comes from. I suspected that the column recreation is kind of expensive, but it doesn't really appear to that obvious. More testing is needed.
Oh yes, it's certainly the DROP and CREATE COLUMN of existing tables. Wow! Alrighty then, removing the migration, here we go.
@lyse Haha, migrations can get rather complicated and pointless IMO 🤣 Kind of reminds me of our other thread, which is also a good read and somewhat related to over-use of the "let's have a migration for every change to the DB we make"
@lyse Haha, migrations can get rather complicated and pointless IMO 🤣 Kind of reminds me of our other thread, which is also a good read and somewhat related to over-use of the "let's have a migration for every change to the DB we make"
@prologic The schema migration itself is easy. When not already on the latest version, loop through all schema patches and see which need to be applied. Suppose, the database schema is at version 0.5, then the SQL queries for versions 0.6, 0.7 and 0.8 are executed one after the other in exactly that order. And with a maiden database it starts out with 0.1 and goes through all the steps. Well, I just restarted with 0.8 being the first supported version, attempts to load older database versions will abort with an error. :-)
The automatic migration at startup simply exist to make *my* life easier. I not only operate this thing locally when developing, but also on a test and production environment. It's very convenient if the existing prod and test data just keep working with a new software version and I don't have to manually migrate things by hand. Simply start the new software version and voilà. I really don't wanna miss that.
Since I don't enjoy doing admin stuff, there is one big thing to not worry about. Even though I messed up one migration step so far and had to fix the production database by hand (removing all existing sessions by hand, so that a new column without default value could be added). It worked flawlessly with the test and local databases before, though, no active sessions did exist anymore at the point of deployment). That raised my adrenaline level.
I reckon I keep the supported versions to a minimum from now on. At least as long as I am absolutely sure that I'm the only person operating that software.
@lyse Sure, but in theory though you only need to keep one migration file, n-1 🤣 -- Not all of them 😅
@lyse Sure, but in theory though you only need to keep one migration file, n-1 🤣 -- Not all of them 😅
@prologic Exactly, for my purposes that's enough. When I started out, I never imagined that migrations will take this long with all my gazillions of tests. :-)