Nice! You're on fire! :)

I'm not sure if I like this design better than the one you proposed on #29.

I'll think about this some more before I weigh in..

We need to make sure this is backwards compatible though (I'm assuming it is)

Yea, this works with the existing config format. I think I'm more of a fan of this because it's very easy to implement and easy to explain.

At the moment I'm implementing a pretty large project with Polo so I'm adding things as I find I need them. If I think I need the other config style I'll whip it up and send a pull request.

This is a good point. The string option is much easier to explain and implement.
And I like simplicity 🤓

So this API might be a winner.

Just thought of something else...
What happens when someone uses self.table_name = something in one of their models?

Should we use the table name or model name in this case?

I'm inclined to think that it should be the model name since we're operating on models. Also probably simpler to implement.

A philosofical reason to operate on model names is the fact that Polo transforms AR records into SQL statments (Not the other way around)

'table.column' is the correct SQL selector for a model configured with self.table_name = something and to me it seems consistent with ActiveRecord query conventions. Ex: http://guides.rubyonrails.org/active_record_querying.html#group

.

I see..
I'm just not sure if this is the route we want to go.

I think we should standardize on model names as opposed to the table name, mostly because Polo isn't too worried about what table those selects are coming from, especially now that we started using Arel for the generation.

We could probably change the line where you do:

instance.class.table_name == table

to something like

 if klass = class_name(field)
   field = field_name(field)
end

instance.class.name == klass

So the specs have namespaced models like AR::Ingredient to make that work the string format would have to be obfuscate 'AR::Ingredient.name' => -> (i) { "Secret" } instead of obfuscate 'ingredients.name' => -> (i) { "Secret" }.

I think the SQL convention is more intuitive for advanced usage since the ActiveRecord pattern is to expose SQL when things stop being simple. Either way it provides a needed capability and I'll update the README accordingly.

that's a good point.
table names would probably make things simpler, I guess they can't get too fancy, not as much as class names at least.

This sounds good!
Let's update the README file and merge this in!

Thanks again, @craigmcnamara

Docs updated!