You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Have you considered using ActiveJob? It allows you to define n generic job that works with any underlying adapter (Sidekiq, DelayedJob etc). By using it you could reduce any adapter-specific things and potentially have less code in the gem.
The job runs async only when turn_async is called at the top of migration class. Having two ways to run a migration can be confusing for developers, as now they need to keep in mind two queues (sync and async, what you describe in the README). Are there are legit use cases when you do NOT want the migration to be async? If not, could we make it simpler for developers by making all migrations async by default, without need to call anything at the top of the class?
The text was updated successfully, but these errors were encountered:
I completely understand the motivation since I encountered the scaling problem situations sometimes and I considered implementing this kind of an async migration support gem.
I have exactly the same questions which @kirs had when I walked through README. Could you answer the questions? If you don't have time to change this gem, I may send PRs to improve based on your answers.
Love the gem! Some high level questions:
Have you considered using ActiveJob? It allows you to define n generic job that works with any underlying adapter (Sidekiq, DelayedJob etc). By using it you could reduce any adapter-specific things and potentially have less code in the gem.
The job runs async only when
turn_async
is called at the top of migration class. Having two ways to run a migration can be confusing for developers, as now they need to keep in mind two queues (sync and async, what you describe in the README). Are there are legit use cases when you do NOT want the migration to be async? If not, could we make it simpler for developers by making all migrations async by default, without need to call anything at the top of the class?The text was updated successfully, but these errors were encountered: