# Batch get method partially implemented? **URL:** \ **Category:** Ruby Client\ **Tags:** query\ **Created:** [January 13, 2018, 9:45pm UTC](https://discuss.aerospike.com/t/batch-get-method-partially-implemented/4861 "2018-01-13T21:45:53Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![zingoba](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.aerospike.com/zingoba/32/605_2.png) [@zingoba](https://discuss.aerospike.com/u/zingoba)\ **Post date:** [January 13, 2018, 9:45pm UTC](https://discuss.aerospike.com/t/batch-get-method-partially-implemented/4861/1 "2018-01-13T21:45:53Z")
Hi all, We are using Aerospike 2.1.1 ruby client on production and querying for some records using the batch\_get() API. We are suspecting that this method is erroneous because a lot of the times it returns nil response for keys that do exist in the cluster. Its definition states a #TODO to implement wait till migration is over. We are suspecting that while migration is happening on the cluster, some of keys move to new partitions and the ruby client still queries on the old partitions and fails to get the record. This inconsistency is causing lots of errors in our system. Could this missing #TODO implementation be the cause for this inconsistency?? If yes, has this already been fixed and released in newer version? If not, will this be taken up soon and fixed? Should we avoid using batch\_get() API till then? Or could there be some other problem with the cluster and that the batch\_get() API is working as it is intended to? Someone please help us out asap as we can’t afford to have data inconsistency on our platform. Thanks. ---
**Author:** ![meher](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.aerospike.com/meher/32/1644_2.png) [@meher](https://discuss.aerospike.com/u/meher)\ **Post date:** [January 15, 2018, 7:39pm UTC](https://discuss.aerospike.com/t/batch-get-method-partially-implemented/4861/2 "2018-01-15T19:39:11Z")
I believe you are correct. The Ruby client doesn’t seem to implement the batch index protocol, based on [this client feature matrix](https://www.aerospike.com/docs/guide/client_matrix.html). You should use a different client (one that supports batch index) if making batch calls during migrations is necessary for your use case. ---
**Author:** ![Jan](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.aerospike.com/jan/32/1124_2.png) [@Jan](https://discuss.aerospike.com/u/Jan)\ **Post date:** [January 16, 2018, 2:12am UTC](https://discuss.aerospike.com/t/batch-get-method-partially-implemented/4861/3 "2018-01-16T02:12:46Z")
That’s correct. The Ruby client still uses the older Batch Direct protocol. The difference between these two batch protocols is explained in the [Aerospike documentation](https://www.aerospike.com/docs/guide/batch.html#batch-protocols); a discussion of the impact of migrations on batch requests using the Batch Direct protocol can be found in this [forum thread](https://discuss.aerospike.com/t/prole-reads-in-case-of-batched-requests/1237). The only possible work-around for the Ruby client is to use single-key requests instead of batch requests. Adding a feature to the client to wait for the migration to finish (as suggested by that TODO) is not a viable solution, as migrations can potentially take a long time. The better solution would be to implement the Batch Index protocol. ---
**Author:** ![Deenbandhu\_Agrawal](https://avatars.discourse-cdn.com/v4/letter/d/b19c9b/32.png) [@Deenbandhu\_Agrawal](https://discuss.aerospike.com/u/Deenbandhu_Agrawal)\ **Post date:** [February 21, 2018, 12:36pm UTC](https://discuss.aerospike.com/t/batch-get-method-partially-implemented/4861/4 "2018-02-21T12:36:29Z")
I am also using ruby client but sometimes partition map is not fetched correctly and hence resulting in wrong partition map and due to which batch\_get starts failing