Waiting for migrations? about aerospike-client-go HOT 3 CLOSED

Another possibility would be to extend the policy, so we can decide whether we need to wait for pending migrations.

from aerospike-client-go.

I like the option to allow users to define a policy to ignore migrations. The default should be as it is currently, with the ability to override via policy. I think that should be the change the goes in.

To do that, we will need to define a new policy, like BatchPolicy, derived from the BasePolicy. This will likely break some clients. We could make it perform type assertions so we can accept either policy.

Ideally, we do not block the operation due to migrations in a namespace unrelated to the operation. So, we will look into that. But for the meantime, it would be great if we can make the change above, because it seems it would be needed regardlessly.

from aerospike-client-go.

The simplest (but not accurate) explanation is that I made a mistake. I removed the migration blocking, added WaitUntilMigrationIsOver to Scan and Query policy, and set the default value to false.

Sorry for the inconvenience.

from aerospike-client-go.