… // whatever nonsense I do

        case operator
      when ‘contains’
        squeel_exp = “proxy.where{ #{filter.attribute_name}.#{sql_operation} ( ‘%#{value}%’ ) }”
      when ‘not contains’
        squeel_exp = “proxy.where{ ( #{filter.attribute_name}.eq nil ) | ( #{filter.attribute_name}.#{sql_operation}( ‘%#{value}%’ ) ) }”
    …
      end

      return eval( squeel_exp )

Let me disclaim that I don’t have any good data for performance impact, but right now I’m in the “get it correct” phase, and performance will come later if necessary.

I work with i18 and usually I keep the translating staff in two places:  in .yml files and in database for models.

Suppose I have model ‘Product’ with ‘name’ attribute. I don’t have real ‘name’ attribute in database, but I have instead ‘name_ru’ and ‘name_en’ real columns. There are numbers of plugins(translatable_columns, rails-translate) helping to realize this approach. The idea is very simple. We should write in model something like ‘translatable_columns :name’ and then expression ‘Product.first.name’ is valid and shows us the ‘name_ru’ or ‘name_en’ depending what I18n.locale is. 

So my proposal (I’m sure lots people’ll like it)

1. We should write in model something like ‘meta_translate :name’ and then we should use the same syntax as before without real ‘name’ attribute in database. If we don’t use ‘meta_translate :name’ in model, everything should work as before.

2. Create class method (let call it ‘meta_where’)  with the same syntax as ‘where’ for ActiveRecord, but this method should understand ‘name_ru’ and ‘name_en’ . For example Product.meta_where(:name=>’something’) should work

even if we don’t have real ‘name’ attribute in database.

Regards, Valen (valenonish@gmail.com)

I think I found a bug :)
I have this scope working fine

scope :on_period, ->(start_period, end_period) {
    where{ ((end_date > start_period ) | (end_date == nil) ) & ( start_date (start_period, end_period) {

    where{ (( start_period < end_date ) | (end_date == nil) ) & ( start_date < end_period) }

  }

it stops working resulting in a where conditions like: WHERE (1)

is that suppose to behave like that?