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.
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.
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?
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.
I am unsure if
flask db migrateis smart enough to generate tables from inherited models but it’ll be interesting to find out.