-
Type:
Task
-
Resolution: Done
-
Affects Version/s: None
-
Component/s: None
We're currently using 3.1.2, not sure if this has been found and corrected with the most recent version, but we've discovered that when using destroy_all the session becomes lost and instead the delete ends up occurring in the collection on the default session.
MOPED: 10.149.1.168:27017 COMMAND database=serps command={:count=>"google_serps", :query=>{"date"=>2013-07-19 00:00:00 UTC, "keyword"=>"personal information protection", "search_engine_id"=>7}} (1.1702ms)
MOPED: 10.149.1.168:27017 QUERY database=serps collection=google_serps selector={"date"=>2013-07-19 00:00:00 UTC, "keyword"=>"personal information protection", "search_engine_id"=>7} flags:slave_ok] limit=0 skip=0 batch_size=nil fields=nil (1.4815ms)
MOPED: 10.149.3.249:27017 COMMAND database=admin command={:ismaster=>1} (1.4548ms)
MOPED: 10.149.3.249:27017 DELETE database=gshiftlabs collection=google_serps selector={"_id"=>"51e976596ff43f03650024f8"} flags:remove_first]
COMMAND database=gshiftlabs command={:getlasterror=>1, :safe=>true} (0.8523ms)
You'll notice that the first 2 use database=serps and then when the delete and command occurs it's using database=gshiftlabs