In my made-up example above, AR would need to be smart enough to recognize the “_like” at the end of the field name and do an email LIKE query instead of an equals query. User.where(active: true, email_like: email) However, I wouldn't mind if a future version of Rails could consider the LIKE query a first-class thing in AR, doing something such as: Its there to vectorize word content and make use of dictionaries, stubbing, lexers, gazetteers, stop-word elimination, and a slew of other tricks none of which apply. Full text search isnt there to do what you think it does. So you see it is sort of an inherent problem. spBlitzEriks answer hits on a lot of good points, but I dont think thats why you shouldnt use Full Text Search.
However, you can’t actually do this: Person.where(:name => "John").where(:lastname => "Smith")īecause the 2nd where clause would need to re-interpret the first where clause (as well, it's totally ambiguous if this should be OR or AND) As well, you will note of course that these return A-Rel objects, which confuses many new developers, which is what allows them to be chained. One of the inherent problems in the design proposal of yours is that the where() clause, by necessity, needs to know about all of its operators so it can construct the correct clause in SQL.
Like ilike sql how to#
Here’s a SO post about how to turn that into a class-level method The reason it’s not first-class in Rails is because the Rails core doesn’t want to write SQL-dependent APIs that would work, say, for PostgreSQL but not MySQL. My understanding is that the AR Query syntax is intended to be database-agnostic.įor these you are supposed to do something akin to this: where('name LIKE ?', "%#%")
0 kommentar(er)
