在从数据库加载对象之前执行一些逻辑

发布于 2024-10-16 17:05:09 字数 858 浏览 3 评论 0原文

情况:

杂志接受投稿。一旦您提交,编辑将安排您提交的内容进行审核。一旦经过审核,您将无法再对其进行编辑。

所以,我在各个州都有服从。 “草稿”、“已排队”、“已审阅”等。大多数进入这些不同状态的切换都是由某些操作触发的,例如,当编辑安排提交时,提交会进入排队状态。简单的豌豆。但是,切换到“已审阅”状态不是由任何操作触发的,它只是在某个日期时间过去之后发生。

对于如何实现这一点,我有两个想法:

  1. 运行每日/每小时的 cron 作业来检查所有排队的提交,并在必要时将它们切换为审核状态。我不喜欢这个因为
    1. 我希望每小时一次,这样我就可以在会议开始前三个小时编辑我提交的内容
    2. 每小时的 cron 作业在 Heroku 上都要花钱,而这个应用程序要么永远不会赚钱,要么在未来的几个月里都不会赚钱
  2. 不知何故构造一个 before_load ActiveRecord 回调,它将在每次加载提交时执行一些逻辑。 “排队?没有?没关系。否则,如果距离会议时间不到三个小时,请将其切换为“已审核”。”

我想征求人们对第二个想法的意见。

  1. 这是一种极其恶臭的方式来实现这一点吗?
  2. 如果是这样,您能建议更好的第三种方法吗?
  3. 如果上述两个问题都是“否”,您能否提供有关每次从数据库加载记录时如何执行此类逻辑的提示? 从 submissions 表(即将成为应用程序中查询最多的表......)中执行 select 之前,我需要始终执行一些逻辑

在 没有好的方法来完成选项二(或者,我希望!选项三),我将通过每日 cron 作业求助于选项一。能够在会议前一天进行编辑就足够了。

The situation:

The magazine accepts submissions. Once you submit, an editor will schedule your submission for review. Once it has been reviewed, you are no longer allowed to edit it.

So, I have submission in various states. "Draft", "queued", "reviewed", etc. Most of the switches into these various states are triggered by some action, e.g., a submission becomes queued when an editor schedules it. Easy peasey. However, the switch into the "reviewed" state is not triggered by any action, it just happens after a certain datetime has passed.

I have two thoughts on how to accomplish this:

  1. Run a daily/hourly cron job to check up on all the queued submissions and switch them to reviewed if necessary. I dislike this because
    1. I would prefer it to be hourly, so that I can edit my submission up to three hours before a meeting starts
    2. Hourly cron jobs cost money on Heroku, and this application will either never make money or won't make money for months and months to come
  2. Somehow construct a before_load ActiveRecord callback, that will perform some logic on submissions each time they are loaded. "Queued? No? Nevermind. Otherwise, switch it to 'Reviewed' if its meeting is less than three hours away."

I wanted to get people's input on the second idea.

  1. Is that an atrociously smelly way to accomplish this?
  2. If so, can you suggest an awesomer third way?
  3. If 'no' to both of the above, can you give tips on how to perform such logic each time a record is loaded from the database? I would need to always perform some logic before doing a select from the submissions table (which is gearing up to be the most-queried table in the app...)

If there's no good way to accomplish Option Two (or, I hope!, Option Three), I will resort to Option One with a daily cron job. Being able to edit up to a day before a meeting will just have to suffice.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

愛上了 2024-10-23 17:05:09

也许使用after_find,虽然你的性能会有点糟糕,如果你做了像before_load这样疯狂的事情,性能也会很糟糕,也就是说金钱可能比性能更重要,如果是这样,我会选择after_find。

Maybe using after_find, although your performance will sort of suck, same goes if you do something as crazy as before_load, performance would suck, that said money might be more important than performance, if that is so, I would go with the after_find.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文