pymongo bugfix后记

2017-09-12 约 1201 字预计阅读 3 分钟

有网友反馈py-mongo-sync同步异常，检查发现curosr[0]取查询结果第一个文档时报错"no such item for Cursor instance"。

这里的逻辑是，根据timestamp查询oplog起始位置，cursor类型是TAILABLE，然后取出第一条oplog，验证timestamp是否一致。

对方mongo版本是v3.4，同步工具在v3.2及更早版本的MongoDB上还没出过类似问题。使用pymongo 3.5.1（最新版本）分别用v3.2和v3.4跑同步测试，在query结果非空的情况下，v3.2正常，v3.4报错，怀疑是不是v3.4做了什么改动，导致dirver不兼容。

进一步排查，cursor[0]读取文档，db端返回了一个错误，意思说tailable和singleBatch两个选项冲突。

1

{'number_returned': 1, 'data': [SON([(u'ok', 0.0), (u'errmsg', u"cannot use tailable option with the 'singleBatch' option"), (u'code', 2), (u'codeName', u'BadValue')])], 'starting_from': 0, 'cursor_id': 0}

cursor.__getitem__(self, index)方法，如果取单个文档，首先对当前cursor进行clone，将limit设置为-1（db返回一条文档并关闭cursor，可参考ntoreturn vs batchSize），表示只读取一条文档。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


 577         if isinstance(index, integer_types):                                                                                                                                            
 578             if index < 0:                                                                                                                                                               
 579                 raise IndexError("Cursor instances do not support negative "                                                                                                            
 580                                  "indices")                                                                                                                                             
 581             clone = self.clone()                                                                                                                                                        
 582             clone.skip(index + self.__skip)                                                                                                                                             
 583             clone.limit(-1)  # use a hard limit                                                                                                                                         
 584             for doc in clone:                                                                                                                                                           
 585                 return doc                                                                                                                                                              
 586             raise IndexError("no such item for Cursor instance")                                                                                                                        
 587         raise TypeError("index %r cannot be applied to Cursor "                                                                                                                         
 588                         "instances" % index)

cursor类型是TAILABLE或TAILABLE_AWAIT，所以query的tailable选项为True； cursor.limit设置为-1，导致query的singleBatch选项为True；二者皆为True，引发冲突。

因为只读取一条文档，limit必须为-1，所以需要把TAILABLE和TAILABLE_AWAIT设置为0，避免选项冲突。

1
2


clone.limit(-1)  # use a hard limit  
clone.__query_flags &= ~CursorType.TAILABLE_AWAIT  # PYTHON-1371

至此，问题解决，说说几点收获：

尽量不要使用cursor索引访问文档，除非是一次性操作

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# 以下是原代码逻辑
coll = self._src_mc['local'].get_collection('oplog.rs', codec_options=bson.codec_options.CodecOptions(document_class=bson.son.SON))
cursor = coll.find({'ts': {'$gte': oplog_start}}, cursor_type=pymongo.cursor.CursorType.TAILABLE_AWAIT, no_cursor_timeout=True)

if cursor[0]['ts'] == oplog_start： # 这里对原始cursor进行clone，执行查询（第一次），然后关闭cursor_cloned

    # 之前在跑同步时，时间戳一致，但此处可能仍有时间长短不一的等待，始终不明所以
    # 原因是下面在调用cursor.next()时会重新执行查询

	while True:
		oplog = cursor.next() # 这里使用原始cursor，执行查询（第二次）
		# handle oplog

提交PR前，确保本地跑通test case，当时仅考虑到TAILABLE的情况，而忽略了TAILABLE_AWAIT
掌握PR流程：提交PR后，如果review未通过，需要修改代码，在你的local分支下继续commit并push到GitHub，新commit会自动追加到该PR，最后由项目维护者完成merge，可以参考collaborating-with-issues-and-pull-requests
最后，很高兴PR能被官方merge :)

目录

pymongo bugfix后记