Comments and suggestions

[aerospike]

Comments and suggestions

[tracker1]

• 1 it's fine to return error codes... when there's an error... when the result is "OK" I wouldn't expect an err object at all... this seriously breaks node callback convention.

//typical node convention
function callback(err, result) {
  if (err) return doSomethingWithError(err);
  ...
}

//when using your module
function callback(err, result) {
  if (err && err.code !== aerospike.status.AEROSPIKE_OK) return doSomethingWithError(err);
  ...
}

I know this breaks compatibility, and would need a full semver bump, but definately suggest at least considering this change.

• 2 awesome, I'm assuming you'll also test against iojs?
• 3 cool... I'm not targetting aerospike myself, was mainly pointing out some things worth considering... I came across your project via a discussion on hacker news, and wanted to see where the node client stood.
• 4 Yes, I mean connection pooling... ie: an example of how best to use the client, when making multiple requests... does your module implement connection pooling, or would one have to create a wrapper around say generic-pool and handle pooling oneself?

[GayathriKaliyamoorthy]

1. Regarding error object - We are seriously considering the implications of moving to model where we do not return error codes. The current users of this module have designed around this model where an error object is returned. And moving away from this will break backward compatibility. We will discuss internally and keep you posted.
2. Regarding node v0.12.0 compatibility - We are in the process of integrating with Nan module, so that Aerospike module is compatible with both node v0.10.* and node v0.12.*. This will be released within this week.
3. Regarding promise based implementation, We discuss this internally and prioritize, meanwhile we accept pull requests from community, so feel free to contribute :)
4. When you say pooling, do you mean connection pooling?

[GayathriKaliyamoorthy]

1. We will consider this seriously and come up with a solution for this.
2. I am not testing against iojs for now, but in the subsequent release I'll test and release note it.
3. Yes we do connection pooling in the underlying implementation. The number of connections that are opened can be configured when creating an aerospike object. By default, there are 300 connections maintained in the connection pool. If the client has to serve more than 300 connections, new connections are opened and reused.

Thanks

[revington]

+1 for the "do not return an error when there is no error"
Also, all the error codes are not specified in the docs like the {code: -1, message: 'Failed to see cluster'}.

Is there any way to disable client->log ? When I can not connect to the cluster this line is sent to stderr
Apr 29 2015 10:53:08 GMT: ERROR(8478) [connect.cc:69] [Connect] - Connecting to Cluster Failed

[streamich]

+1 for not using underlying C driver but implement the protocol in pure JS.

Also, open source the protocol, if it is not.

[bbulkow]

The protocol has been defined, and both the client and server are open source, so anyone is able to write a client. Anyone who would like to write a pure JS client is welcome to.

[GayathriKaliyamoorthy]

All issues in this discussion are addressed except for promise support. For updates on promise support refer issue #78 . Closing this issue.