configuring in an initializer?

[jrochkind]

The README docs:

GoodJob configuration can be placed within Rails config directory for all environments (config/application.rb), within a particular environment (e.g. config/environments/development.rb), or within an initializer (e.g. config/initializers/good_job.rb).

One example of doing it in an initializer would look like:

GoodJob.preserve_job_records = true

But if I want to also set cleanup_discarded_jobs (which frankly seems to me like it should be the default recommended configuration, both preserve_job_records and cleanup_discarded_jobs; it's clear to me that is what I want, but it was a bit confusing to find)....

GoodJob.cleanup_discarded_jobs = true doesn't work. Is there any good way to set cleanup_discarded_jobs in an initializer?

Some configuration options seem to be available off GoodJob, but others not? I would love to put all my cross-environment GoodJob config in an initializer.

[bensheldon]

It's safe to use all of the config.good_job.... settings inside of an initializer: #380 (comment)

I'd recommend entirely using the config settings, and maybe the Readme should reflect that.

I think the only GoodJob... global setting that doesn't have an equivalent in config.good_job... is GoodJob.active_record_parent_class.

I'd love feedback of how to make it clearer in the Readme. Also, the defaults will become better in GoodJob 3.0.

[jrochkind]

Why wouldn't we want to update the README before the 3.0 release, to get in there first? If the Rails.application.config is the preferred way to do it, for consistency accross all config? But maybe that's not actually the preferred way?

I was confused with some config elements being set one way and some another, and it not being documented which should be set which way -- but I am just one person, I may not be typical! Either way, okay, your call, if you don't want to make the README consistent in that way?

Good to know good_job 3.0 is coming shortly -- I will perhaps pause our attempt to integrate good_job in our app until 3.0 comes out, and start with that one! No reason to get everything in order for 2.0 now and then just have to upgrade and change things!

good_job is looking pretty nice! Except I'm still a bit baffled at the lack of First-in-first-out mentioned in #624 . I'm not sure if I'm comfortable switching over to a queue that isn't first-in-first-out... although I guess if nobody else has wanted that or noticed maybe I'm wrong that it matters that much, but it seems disturbing to me. Also to fully migrate we'd need to, I guess, assign priorities to everything that we were currently use queue-order-of-precedence to handle, since good_job doesn't do that, as mentioned in that discussion.

[bensheldon]

Sorry, didn't mean to throw cold water on your work right now. 3.0 will not have any major changes, just removing deprecations and swapping some of the behaviors (preserve jobs, and auto-delete them will become the default).

I mostly don't want you to go to the trouble of updating the readme, and then those sections being almost immediately deleted because they won't be necessary. Right now a not-insignificant part of the readme is focused on configurating towards what in 3.0 will be the default.

But also, if I hit my deadline, I assume that waiting a week won't block you.

I will reply more deeply on the FIFO issue. I really hasn't come up, but I can explain more over there.

[jrochkind]

Ah, I get it.

So the current README doesn't have the 3.0 chagnes yet... do you have a branch that does that I can PR against, or you just haven't updated the README for 3.0 yet?

[bensheldon]

My doctrine has been to only use major releases for deprecations and functional changes (e.g. changing preserve-jobs default from false to true) not to introduce new features. So everything that will exist in 3.0 currently exists now, it just may be disabled by default.

The functional changes for 3.0 are in #545, which is simply changing the default values. I'll also make 1 more PR which removes deprecations. And that's it. (unless there are any unconsidered surprises from that).

[bensheldon]

And I'll add that the 1.0 -> 2.0 upgrade cycle had a change to the locking strategy that required an orchestrated production migration. 2.0 -> 3.0 doesn't have anything like that.