)]}'
{"swift/container/server.py":[{"author":{"_account_id":15343,"name":"Tim Burke","email":"tburke@nvidia.com","username":"tburke"},"change_message_id":"a71d5873b2f24fee23276dcf9c891013116bc62a","unresolved":false,"context_lines":[{"line_number":618,"context_line":"        else:"},{"line_number":619,"context_line":"            # Use the retired db while container is in process of sharding,"},{"line_number":620,"context_line":"            # otherwise use current db"},{"line_number":621,"context_line":"            src_broker \u003d broker.get_brokers()[0]"},{"line_number":622,"context_line":"            include_deleted \u003d items \u003d\u003d \u0027all\u0027"},{"line_number":623,"context_line":"            container_list \u003d src_broker.list_objects_iter("},{"line_number":624,"context_line":"                limit, marker, end_marker, prefix, delimiter, path,"}],"source_content_type":"text/x-python","patch_set":1,"id":"3fa0c359_f4c0202d","line":621,"updated":"2018-02-07 01:21:47.000000000","message":"I\u0027m not necessarily opposed to this... but I wonder if we could/should differentiate between\n\n* got written to shard db and will be dealt with as a misplaced object vs.\n* got written to shard db and will get sent out as we continue cleaving.\n\nIn the former case, we should deal with the row quickly and get it where it belongs. In the latter, though, we may \"own\" the row for quite a while...\n\nThe good news is, I *think* we could just compare marker/end_marker (depending on reversed) against own_shard_range... since we tell the proxy \"these are the only names I\u0027m responsible for\" by way of filler_sr.\n\nMeh. Better as future work, I suppose.","commit_id":"f3e3890ce60f6ab22eb7d30b667609d42540ad6d"},{"author":{"_account_id":7847,"name":"Alistair Coles","email":"alistairncoles@gmail.com","username":"acoles"},"change_message_id":"d73a0d020c50c7e70ac9240e166b30aa08efed65","unresolved":false,"context_lines":[{"line_number":618,"context_line":"        else:"},{"line_number":619,"context_line":"            # Use the retired db while container is in process of sharding,"},{"line_number":620,"context_line":"            # otherwise use current db"},{"line_number":621,"context_line":"            src_broker \u003d broker.get_brokers()[0]"},{"line_number":622,"context_line":"            include_deleted \u003d items \u003d\u003d \u0027all\u0027"},{"line_number":623,"context_line":"            container_list \u003d src_broker.list_objects_iter("},{"line_number":624,"context_line":"                limit, marker, end_marker, prefix, delimiter, path,"}],"source_content_type":"text/x-python","patch_set":1,"id":"3fa0c359_6ac74047","line":621,"in_reply_to":"3fa0c359_f4c0202d","updated":"2018-02-07 10:33:04.000000000","message":"The bad news is that if you are filling a container with alphabetically increasing object names, then those will be landing in the final shard range which is that last to cleave, so you won\u0027t see those objects in listing until all cleaving is complete.\n\nIf we thought that was the commoner case, we could reverse the order of finding and cleaving.\n\nThat said, this is a tactical scope reduction. In future what we need is a merge engine that takes multiple sources yeilding objects and does the right thing to produce a merged listing. Ideally that engine would be re-usable here and in the proxy.","commit_id":"f3e3890ce60f6ab22eb7d30b667609d42540ad6d"}]}