Both of these will work: (as will many more)
.where(MyModel.arel_attribut(:id).eq(MyModel.arel_attribute(:id)))
# OR
.where(Arel.sql("1=1"))
This "always true" type conditioning was generally used for query assembly in Stored Procedures or in String concatenation where you would always have a WHERE clause but then may not have any conditions e.g.
SET @sqlString = 'SELECT * FROM table WHERE 1=1'
IF (@var IS NOT NULL)
SET @sqlString = @sqlString + ' AND "column" LIKE ''%' + @var + '%'' '
EXEC (@sqlString)
# OR
sqlString = "SELECT * FROM table WHERE 1=1"
if someCondition
sqlString = sqlString + " AND column = " + value
end if
but all of this seems antiquated (especially in regards to Rails).
ActiveRecord avoids all of this by using a library called Arel
which assembles the SQL just prior to execution.
ActiveRecord provides a convenience method (#all
) to generate a similar concept of select everything. You can just call MyModel.all
which will return a chainable ActiveRecord::Relation
you can then apply conditions, or not, you can add ORDER BY, GROUP BY, LIMIT, HAVING, etc. statements, it is up to you in code and at runtime.
You can utilize this chainability to "assemble" these conditions as you see fit e.g.
q = MyModel.all
q.where!(name: "engineersmnky") if find_my_name?
These calls do not even have to make "logical" sense in SQL statement order because Arel
knows the order in which to assemble these statements in order to form a coherent query. e.g.
MyModel.having("COUNT(column) > 1")
.order(:name)
.group(:name)
.select("name, COUNT(column) AS counter")
.where(x: 12)
.limit(2)
This is completely jumbled from a SQL standpoint but when the actual query is assembled it will be ordered correctly.