Conversation

Notices

1. Aral Balkan (aral@mastodon.ar.al)'s status on Wednesday, 30-Aug-2023 02:09:01 JST Aral Balkan

   Been doing some research into implementing migrations for Domain’s JSDB database (basically, JavaScript data structure migration) and it’s amazing to me how many of the solutions out there use semver to version databases with no good reason.

   If your database requires a migration, it is a major version. Where does minor and patch even come into it? Why complicate it beyond version 1, 2, 3… etc.?

   I do wish folks would stop and think for a moment before adopting things without understanding them.

   • Aral Balkan (aral@mastodon.ar.al)'s status on Wednesday, 30-Aug-2023 02:13:03 JST Aral Balkan

     in reply to

     I’m actually now wondering if implementing lazy migrations at the object level is madness or not.

     e.g., myDatabase.someTable.someObject.latest().someProperty

     Where the latest method ensures migrations for the object are lazily run as necessary.

     Of course, that would complicate authoring quite a bit because if you forgot that latest() call things would go poof!

     Hmm… if only there was a way to run an initiliser when using Object.create()… #JSDB already uses proxies so maybe?

     #js #database

   • Aral Balkan (aral@mastodon.ar.al)'s status on Wednesday, 30-Aug-2023 03:23:32 JST Aral Balkan

     in reply to

     • Claudius

     @claudius Read an article where someone was suggesting using hashes for the same reason. They were actually essentially creating a basic directed acyclic graph with the migrations. Neat but rather overkill for my use case, I think (says the guy looking into if he can use a Proxy to automatically carry out necessary migrations at the object-level for persisted classes) :)

   • Claudius (claudius@imd.social)'s status on Wednesday, 30-Aug-2023 03:23:34 JST Claudius

     in reply to

     @aral rails timestamps the migration (iso8601) and has one table that keeps track of applied migrations. This is a good idea in a scenario where Multiple Devs might add migrations on separate branches where a single version number would fall short.

   • Aral Balkan (aral@mastodon.ar.al)'s status on Wednesday, 30-Aug-2023 03:24:44 JST Aral Balkan

     in reply to

     • Matt Boehm

     @bigolewannabe Yeah, that would make sense.

   • Matt Boehm (bigolewannabe@hachyderm.io)'s status on Wednesday, 30-Aug-2023 03:24:45 JST Matt Boehm

     in reply to

     @aral
     Possibly one reason is to keep the version of the app in line. Linear increase of the DB schema means you basically need a decoder ring to figure out which app version uses which schema number.

   • Aral Balkan (aral@mastodon.ar.al)'s status on Wednesday, 30-Aug-2023 03:44:40 JST Aral Balkan

     in reply to

     • Claudius

     @claudius I quite like the idea that each database object (be it a collection or a single object) has its own migration code encapsulated within it. So if from version 2 to 3 only Collection X and Object Y have changed, they can lazily carry out their migrations the first time they’re accessed.

     Just had a quick look at JSDB to remind myself how I’m doing things and it should work by having the Proxy methods carry out the migration check.

     Going to spike it and see how/if it works :)

   • Claudius (claudius@imd.social)'s status on Wednesday, 30-Aug-2023 03:44:42 JST Claudius

     in reply to

     @aral yeah solving 95% is probably the way to go. You can always get more complicated later without too much hassle.