Utilizzando lo stile rails 3 come scriverei l'opposto di:
Foo.includes(:bar).where(:bars=>{:id=>nil})Voglio trovare dove ID NON è zero. Provai:
Foo.includes(:bar).where(:bars=>{:id=>!nil}).to_sqlMa questo ritorna:
=> "SELECT \"foos\".* FROM \"foos\" WHERE (\"bars\".\"id\" = 1)"Non è sicuramente quello di cui ho bisogno e sembra quasi un bug in ARel.
Risposte:
Il modo canonico per farlo con Rails 3:
Foo.includes(:bar).where("bars.id IS NOT NULL")ActiveRecord 4.0 e versioni successive where.notconsentono di eseguire questa operazione:
Foo.includes(:bar).where.not('bars.id' => nil)
Foo.includes(:bar).where.not(bars: { id: nil })Quando lavoro con gli ambiti tra le tabelle, preferisco sfruttare in mergemodo da poter utilizzare gli ambiti esistenti più facilmente.
Foo.includes(:bar).merge(Bar.where.not(id: nil))Inoltre, poiché includesnon sempre si sceglie una strategia di join, è necessario utilizzare anche referencesqui, altrimenti si potrebbe finire con SQL non valido.
Foo.includes(:bar)
.references(:bar)
.merge(Bar.where.not(id: nil))rails undefined method 'not_eq' for :confirmed_at:Symbol..
wherecondizioni sta semplicemente costruendo un AST, non colpisce il database fino a quando non si raggiunge un metodo terminale come eacho to_a. La creazione della query non è un problema di prestazioni; quello che stai richiedendo dal database è.
Non è un bug in ARel, è un bug nella tua logica.
Quello che vuoi qui è:
Foo.includes(:bar).where(Bar.arel_table[:id].not_eq(nil))true, che è un valore booleano. :id => trueti porta id = 1in SQLese.
field_name != 'NULL'.
id = 't':)
Per Rails4:
Quindi, quello che vuoi è un join interno, quindi dovresti semplicemente usare il predicato join:
Foo.joins(:bar)
Select * from Foo Inner Join Bars ...Ma, per la cronaca, se vuoi una condizione "NOT NULL" usa semplicemente il non predicato:
Foo.includes(:bar).where.not(bars: {id: nil})
Select * from Foo Left Outer Join Bars on .. WHERE bars.id IS NOT NULLNota che questa sintassi riporta una deprecazione (parla di uno snippet di stringa SQL, ma immagino che la condizione di hash sia cambiata in stringa nel parser?), Quindi assicurati di aggiungere i riferimenti alla fine:
Foo.includes(:bar).where.not(bars: {id: nil}).references(:bar)AVVISO DI DEPRECAZIONE: Sembra che tu sia desideroso di caricare le tabelle (una delle: ....) a cui si fa riferimento in uno snippet SQL di stringa. Per esempio:
Post.includes(:comments).where("comments.title = 'foo'")Attualmente, Active Record riconosce la tabella nella stringa e sa UNIRE la tabella dei commenti alla query, anziché caricare i commenti in una query separata. Tuttavia, farlo senza scrivere un parser SQL completo è intrinsecamente imperfetto. Poiché non vogliamo scrivere un parser SQL, stiamo rimuovendo questa funzionalità. Da ora in poi, devi dire esplicitamente ad Active Record quando fai riferimento a una tabella da una stringa:
Post.includes(:comments).where("comments.title = 'foo'").references(:comments)
referenceschiamata mi ha aiutato!
Non sono sicuro che sia utile, ma è quello che ha funzionato per me in Rails 4
Foo.where.not(bar: nil)Con Rails 4 è facile:
Foo.includes(:bar).where.not(bars: {id: nil})Vedi anche: http://guides.rubyonrails.org/active_record_querying.html#not-conditions
!nilrestituiscetruein Ruby, e AREL traducetruead1in una query SQL. Quindi la query generata è in effetti ciò che hai richiesto: non si trattava di un bug ARel.