Make with_indifferent_access optional

[godfat]

This is a feature request that we could choose to not use with_indifferent_access.
We're running several processes, and some would load rails, and some would not.
Current with this would give us different results upon different context, which I think
it's quite bad:

if result.first.respond_to?(:with_indifferent_access)
  output.map(&:with_indifferent_access)
else
  output.each(&INDIFFERENTIATOR)
end

Can we have an option like:

Que.hash_mode = :INDIFFERENTIATOR
Que.hash_mode = :with_indifferent_access
Que.hash_mode = :off # to turn it off completely
Que.hash_mode = :auto # could be what we have not

So that we could make this more deterministic?
Thanks!

/cc @mz026

[chanks]

If you're loading Rails in some processes and not others, I think you're already introducing a good amount of uncertainty in the behavior of each process due to its core extensions and patches, right? Are you sure that's a good idea?

[godfat]

It's not because Rails monkey patches so much, and so it's good to try not to rely on monkey patches as much as possible. Less dependencies, less coupled, less interfering, less complexity, more flexibility.

I think libraries should do less or at least should make it configurable so that it could properly fit into everything and make less surprise. One could still use Que with or without Rails in different projects, and getting different results automatically is very surprising to me.

On the other hand, I am trying very hard to escape from Rails. So one day we would try to move off everything from Rails. This is a process. :)

[chanks]

Hmm. So, what I'm picturing is a configuration option to set a callable object that would be responsible for converting the args hashes from the DB to a more usable format. It could default to the INDIFFERENTIATOR proc, although maybe I'd rename it something friendlier if people start needing to be aware of it. I think it'd be preferable for the Railtie to default it to call with_indifferent_access, since I expect that's the kind of result that most Rails users would expect. That would keep the defaults the same, but allow them to be overridden in an edge case like yours.

Does that sound reasonable? I can knock it out on Friday, I think.

(In 1.0 I've already changed the default behavior to just symbolize all keys, since symbols are GC-able in most current implementations, but even so I think it'll make sense to keep things configurable).

[godfat]

Yes, that makes prefect sense as long as it could be configured. Thank you very much!

Personally I am not a fan of symbolized keys though. Consider we're passing string keys and after deserialized it suddenly changed to symbol keys... I think the issue is that the information just lost during serialization. At any rate, as long as it's configurable, I am ok with any defaults :)

Thanks again!

[chanks]

Just pushed a configuration option to change this, thanks for the suggestion!

[godfat]

Great, thank you! I would set it to :itself.to_proc then. You could also set it to :with_indifferent_access.to_proc to avoid converting proc twice.

[chanks]

Good point, thanks!

On Fri, May 22, 2015 at 3:02 PM, Lin Jen-Shin (godfat) <
notifications@github.com> wrote:

Great, thank you! I would set it to :itself.to_proc then. You could also
set it to :with_indifferent_access.to_proc to avoid converting proc twice.

—
Reply to this email directly or view it on GitHub
#113 (comment).