Closed bfcoder closed 6 years ago
As this gem appears to be dead, I have released another gem from a fork of this one: https://rubygems.org/gems/apartment-activejob-que
I have only verified this works with Que. I probably works with others as well.
i could just be being dense but i don't understand what the goal is here? the diff appear to be doing two things which require explanation as to why:
initialize
, as opposed to serialize
enqueue
in looking at active job while reviewing this it seems like better practice would be to utilise around_perform
anyways.
I suppose recording the current tenant could be kept in the serialize.
But the switching to public tenant must happen during the enqueue. At least in the case of que, jobs are only worked from the public tenant. So if you don't switch to the public tenant, your jobs will just sit there, never getting worked.
right, i get it. this is typically achieved by adding the job table to your apartment excluded models. does que use activerecord?
It does use activerecord but as far as I can tell it doesn't have a model you can place into the config.excluded_models
.
okay. well, i don't think that forcing jobs to be enqueued on the public tenant will be appropriate for all users of apartment-activejob. there might be people who have per-tenant job queues.
Ok, that makes sense. I have the gem for those that use Que then. Thanks for your input!
At least in the case of Que, jobs will only be worked when on the public tenant.
This makes it so jobs are enqueued on the public tenant, then switched to the current tenant when worked.