Closed samuelclay closed 11 years ago
thanks for the ticket @samuelclay this is an interesting one - because mongoengine just passes the read preference along unhindered (but just validated).
Ah found a bug! The method applying the read preference returns a clone and I failed to pass that clone on.
Fixed in master and will release in 0.8.2
In the meantime you can use:
MFetchHistory.objects.read_preference(pymongo.ReadPreference.PRIMARY).get(feed_id=4100012)
:tada:
Steps to reproduce:
1) Create a row on a replica set that is experiencing slave lag (and they all do, even if it's just one second) 2) Query for that new row using read preference = PRIMARY 3) Half of the time the query comes back with the row not found, other times it's found. Using pymongo directly it works fine.
And using Mongoengine's read preference:
Notice that the pymongo call always works, but the mongoengine call fails half the time. It is probably using a read preference of PRIMARY_PREFERRED insead of PRIMARY, which causes it to not find the row.