• @Deebster @erlend_sh Yeah… we just don’t like to commit. Like just yet.

    I really need to give myself a weekend to go over the database schema and find something I’m happy with that I want to keep.

    That’s like the biggest reason I’m not committing to anything but "pre"s yet :blobfoxmeltsob:

    Just my life has been rather chaotic over the last few months. And now a new job soon and everything.

    inb4 making it on https://0ver.org/ soon

    • @Deebster @erlend_sh the biggest blockers regarding the database schema design right now are:

      • Bring-your-own-domain
      • Settings and preferences
      • System account (for authorized fetch mode)

      That requires a lot of consideration though, and I’d also like to subdivide the accounts table more for two reasons:

      • Agnosticism over protocols (maybe ActivityPub won’t be the only protocol we want to support in the future)
      • If we can get under 16 columns, we can disable support for 32 columns in Diesel and save build time

      That’s basically it. Aside from that there’s not too much I’d change in an incompatible way

      • Deebster@programming.dev
        link
        fedilink
        English
        arrow-up
        1
        ·
        1 year ago

        Agnosticism over protocols (maybe ActivityPub won’t be the only protocol we want to support in the future)

        If that’s simple to do, it’s worth waiting for, but if it’s trickier then I’ve learnt the importance of remembering YAGNI and KISS (and that database migration scripts aren’t that hard). Of course, third party database queries aren’t as simple to update but perhaps your API will be all implementers need.

        If we can get under 16 columns, we can disable support for 32 columns in Diesel and save build time

        This does seem worthwhile, just to speed up development cycles.