Shouichi Kamiya

> But we shouldn't simply pass all `**kwargs` to `Worker` but define some options that are shared in the RQ instance instead. In other words let's try to keep Flask-RQ2...

Thank you for the response! > I agree that pluggable pagination would be great. Is this something you'd want to look into? Yes. But the question I have is plug-and-play...

Ahh, cool! We can take the same strategy for pagination. Personally not providing pagination by default seems dangerous. We don't want to blow up the production server by selecting millions...

We can implement pagination in administrate. If it's simple enough, we can go that way. What do you think?

Yes, we should avoid adding complexity to administrate if possible. So the plan should look like the following. 1. Introduce an abstraction layer so that users can swap pagination libraries...

Thank you for the confirmation! I'll work on that. I've been very busy and it would take some time though.

We implemented sorting by relationship field by something like this. ``` class Comment has_one :moderation delegate :state, to: :moderation, prefix: true end class Moderation belongs_to :comment enum :approved, :disapproved end...

Unfortunately simply changing `maintenance_tasks_runs.id` to uuid did not work because of the following code. https://github.com/Shopify/maintenance_tasks/blob/e64cdf0c265f67dd3a487c5fb0db8dc9df5464d4/app/models/maintenance_tasks/task_data.rb#L44

The project only uses sqlite for testing. It seems that the first step is using both sqlite and postgres for testing. Is this the right direction @etiennebarrie ?

Mmm, maybe we could use blob as a primary key and store uuid. I'll take a look.