WIP: v4 #642
WIP: v4 #642
Conversation
…ch back.
BREAKING CHANGE:
This change makes all the code that rely on the features provided by Bluebird not working
anymore. For example, `redis.get('foo').timeout(500)` now should be failed since the native
Promise doesn't support the `timeout` method.
You can switch back to the Bluebird implementation by setting `Redis.Promise`:
```
const Redis = require('ioredis')
Redis.Promise = require('bluebird')
const redis = new Redis()
// Use bluebird
assert.equal(redis.get().constructor, require('bluebird'))
// You can change the Promise implementation at any time:
Redis.Promise = global.Promise
assert.equal(redis.get().constructor, global.Promise)
```
BREAKING CHANGE: The `new` keyword is required explicitly. So `Redis(/* options */)` will not work, use `new Redis(/* options */)` instead.
|
Cluster:
Other:
|
A disconnection won't lead the update of slots immediatially. A cluster will consider a master to be failing only after NODE_TIMEOUT has elapsed. So most of time we only need refetch the slots in two different situations (https://redis.io/topics/cluster-spec#clients-first-connection-and-handling-of-redirections):
However, given a failing of a slave won't trigger a
Good idea. I've seriously considered removing callback support. However, what makes me tend to keep callback support in this major version is that many built-in functions ( We may do this on the next major version, which only supports node >= v8 that support async functions. |
…er command #634, #61 BREAKING CHANGE: The maxRetriesPerRequest is set to 20 instead of null (same behavior as ioredis v3) by default. So when a redis server is down, pending commands won't wait forever until the connection become alive, instead, they only wait about 10s (depends on the retryStrategy option)
BREAKING CHANGE: `Cluster#connect()` will be resolved when the connection status become `ready` instead of `connect`.
BREAKING CHANGE:
`Redis#connect()` will be resolved when status is ready
instead of `connect`:
```
const redis = new Redis({ lazyConnect: true })
redis.connect().then(() => {
assert(redis.status === 'ready')
})
```
Offline queue should be enabled on the internal cluster nodes so that we don't need to wait for the `ready` event before sending commands to the node.
|
Just release a beta version v4.0.0-0. The remaining issues will be resolved in the next beta version. |
In this major version, we would drop the support for node 4 (#408) in order to use the built-in Promise instead of bluebird (#639 ).
Other plans are:
SCANand ES6 Iterators.Cluster related:
Any other ideas? @shaharmor @Salakar @AVVS