在Laravel中，将数据库更新推迟到周末，并能够查看浏览器中的待处理更新
我有一个Laravel应用程序，用户可以在数据上执行基本的CRUD操作。但是，数据必须在一周内保持不变。每周结束时，应批量记录和执行CRUD请求。
用户的故事是他们正在为下周的数据安排修改。他们应该能够以固定状态查看当前一周的数据，因为知道整个星期将保持稳定。然后，他们可以单独查看待定更改的时间表，该时间表将计划在本周结束时生效。
简而言之：将数据库修改推迟到本周末，但是用户可以查看下周的待处理修改。
我正在使用Laravel的
我考虑使用作业类'delay方法将作业的调度延迟到本周结束，但是如果待处理的作业整个星期都在队列中，则没有提供给用户的信息在一周内。
我想出的另一个选项是创建一个代表当前待处理数据库更改的单独表。工作将根据要求立即派遣。但是，调度方法不会修改数据库本身，而是在此新表中创建记录。在本周结束时，该表中的所有数据库修改将在计划的任务中执行。
我不喜欢这种方法，因为它感觉多余/混乱。 CRUD操作被整齐地封装为作业，但是当存储在待处理的修改表上时，该数据被复制。此外，可以在一周的任何时候派遣工作本身，但没有与修改数据本身的时间点具有内在连接。
也许为每个CRUD操作创建两个作业，例如createperson和schedulecreateperson？
我觉得有一种更干净的方法可以更好地利用现有的作业界面。
I have a Laravel app where users can perform basic CRUD operations on data. However, the data must remain unchanged during the week. CRUD requests should be logged and executed in bulk at the end of each week.
The user story is that they are scheduling modifications for next week's data. They should be able to view the current week's data in its fixed state, knowing that it will remain constant for the entire week. Then, they can separately view a timeline of pending changes which will are scheduled to take effect at the end of the current week.
In short: database modifications are deferred until the end of the week, but the user can view next week's pending modifications.
I'm using Laravel's Job classes to encapsulate and log the requests.
I considered using the Job class' delay method to delay the job's dispatch until the end of the week, but if the pending job is sitting in the queue the whole week, there's no information to provide to the user during the week.
The other option I came up with is to create a separate table representing the current week's pending database alterations. Jobs will dispatch immediately, upon request. However, the dispatch method will not modify the database itself, but will create a record in this new table. At the end of the week, all the database modifications sitting in this table will be executed in a scheduled task.
I don't like this approach because it feels redundant/messy. CRUD operations are neatly encapsulated as jobs, but that data is duplicated when stored on the pending modification table. Furthermore, the job itself can be dispatched at any point during the week, but has no intrinsic connection to the point in time at which the data itself is modified.
Maybe create two jobs for each CRUD operation, e.g. CreatePerson and ScheduleCreatePerson?
I feel like there's a cleaner way to do this that better leverages the existing job interface.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论