• hendrik@palaver.p3x.de
    link
    fedilink
    English
    arrow-up
    1
    ·
    edit-2
    15 days ago

    I’m considering starting to work on this. But I need some advice: Where do I put the task to periodically ckeck the database and send out the posts? Do I introduce yet another cronjob? Or lump everything together with the maintenance task, make it run every 5minutes and add some logic to skip maintenance unless once at 2am? Is there another clever way to trigger a periodic task?

    • Rimu@piefed.socialOP
      link
      fedilink
      English
      arrow-up
      2
      ·
      15 days ago

      That’s great :)

      The daily maintenance task takes a long time to run, too long to run often.

      Also that function is already doing too many things - we’ll need a new function in cli.py with a new cron job.

      The DB model is worth getting right because the ramifications will be everywhere.

      My first thought is to add a ‘status’ field (bool) onto the Post model and set that when moving a post from draft to published. That way we won’t have two models to keep in sync (“Post” and “ScheduledPost”) and no extra dependent models/tables (Poll, post_tag equivalents for scheduled posts). But then every time we run a query on Posts we’d need to filter out the unpublished posts. We already do this to filter out deleted posts which leads me to:

      Another possibility would be to use the value of ‘status’ (int, not bool) to represent scheduled, published and deleted states. This would mean we don’t have an extra filter in play to hide deleted posts - 99% of the time we’ll only want published Posts.

      How’s that sound?

      • hendrik@palaver.p3x.de
        link
        fedilink
        English
        arrow-up
        1
        ·
        15 days ago

        Thanks. I’ll just make it a separate cronjob, then.

        I was hoping the object-relational mapper can do some magic for us. Like make ScheduledPost inherit from the class Post and just add a timestamp. But I haven’t looked at that yet. Your other two ideas sound fine as well. I guess I’ll just start, and decide once I’m buried in the code. That way I’ll see which one feels clean to type out… In case of doubt you can intervene, I guess this will be a small part of the changes anyway. I also have to come up with some UI etc.

        • Rimu@piefed.socialOP
          link
          fedilink
          English
          arrow-up
          2
          ·
          15 days ago

          I am unsure if flask db migrate is smart enough to generate tables from inherited models but it’ll be interesting to find out.