-
Type:
Improvement
-
Resolution: Won't Do
-
Priority:
Unknown
-
None
-
Affects Version/s: None
-
Component/s: None
-
Labels:None
The new "broken_and = false" behavior as documented here looks horribly confusing. As a user I have no idea how this works, and I'm scared to ever use the `.and` method.
Here is the example:
Band.where(id: 1)
.and({year: {'$in' => [2020]}}, {year: {'$in' => [2021]}})
.where(id: 2)
#<Mongoid::Criteria selector:
{ "_id"=>1,
"year"=>{"$in"=>[2020]},
"$and"=>[{"year"=>{"$in"=>[2021]}}, {"_id"=>2}] } # WAT?!
A .where expression coming after an .and should not be retroactively inserted into the last condition of the and... it's completely bizarre.
I challenge you to do an internal poll within the MongoDB office and see if anyone can guess this behavior. I will bet that no one will able to.
I think the following would make sense:
Option A) Preferred -- Mongo query is generated EXACTLY as the Ruby code reads. Most intuitive, users will LOVE you.
Band.where(id: 1)
.and({year: {'$in' => [2020]}}, {year: {'$in' => [2021]}})
.where(id: 2)
#<Mongoid::Criteria selector:
{ "_id"=>1,
"$and"=>[{"year"=>{"$in"=>[2020]}, "year"=>{"$in"=>[2021]}}],
"_id"=>2 }
Option B) .and combines with the .where BEFORE it.
#<Mongoid::Criteria selector:
{ "$and"=>[{"_id"=>1}, {"year"=>{"$in"=>[2020]}, "year"=>{"$in"=>[2021]}}],
"_id"=>2 }
I strongly prefer option A. I think it was huge mistake to ever try to match ActiveRecord's behavior. But option B, if it is clearly documented in BOLD RED font is also acceptable.