Different / inconsistency across different SDK's

I was wondering if there is a reason why when using different SDK’ s with N1QL there is diffrent ways to get the data ? For example in NodeJs 3.2 if i run a query the result has a data element which returns the response from query in a form of array. Now if I use PHP 3.x the data is returned in a element called rows. Not to be a pest but if you work with multiple sdk’s it would be much easier if it would be same across all.
Or is there a specific reason for that ?

Hi @aponnath ,

Thank you for your question.

In general the SDK should follow the style of the relevant programming language. This can sometimes lead to differences in return types, especially with dynamically typed programming languages.

I hope that helps!

Thanks but i think the bigger problem is that at couchbase a does not talk to b when it comes to SDK’s. NodeJs SDK had rows and moved to data. And i just don’t see a language specific spec which says it should be rows vs data but where you guys have control it would make sense to stay confirm.

Another example is on SubDoc operation if user wants to create a parent if not present. in php i have to set a value for isXattr false and createPath for true. In old version it was a simple [‘createPath’ => true]. Even in NodeJs 4.x its is still { createPath: true }. These might seem small but if one like me works on 3 SDK’s and each has its own flavors its not fun,

Also it would be great if you guys publish a changelog which list all changes in new version so one can search for them in its code instead of having to troubleshoot all broken stuff

Hey @aponnath, sorry you’re running into inconsistencies. Could I ask, what are the SDKs/versions you’re using? That may help me understand the areas you’re concerned with most.

Actually, we work quite hard at making sure everyone is coordinated. While it’s not a formal language specification, we do create specifications for all of the official SDKs and even publish them publicly in the sdk-rfcs. The SDK3 Foundation and the SDK3 Query are particularly relevant to your questions. We have long had an SDK/Connectors team understanding of an API version for SDKs that follows semantic versioning, and we are now communicating those details a bit more formally with a first class definition of an SDK API Specification in multiple places in the documentation. We try quite hard, and while we’re not perfect yet (nor is the industry), we’ll keep trying!

That said, we aim to be as common as possible while respecting platform idioms as much as possible. This is non-trivial. Particularly when you have languages like PHP where there isn’t really much asynchronous support compared to Node.js where it is always asynchronous. Another example is Node.js and Python have pretty straightforward, canonical ways of using JSON to Scala which has a good half-dozen libraries with trade-offs (I could rant further here). Sometimes that means we allow for variations between SDKs to meet the platform idiom concerns.

Given that you’re describing Sub-Document operations, XAttrs and the related create options, I get the impression that you’re an advanced user. :slight_smile: We were just talking about an ambiguity for this case the other day in a meeting and how we’ll work to make things more common. If it’s just a bug against the spec, we fix it and release note it.

We publish both migration guides (like this one for Node.js 4.0) and release notes per release. Those should cover any material changes. We may miss something on occasion though. When we do, please let us know. Best way to let us know would be to file an issue or if you think it’s something under-covered, hit the documentation feedback link.

[ingenthr] This issue is less with the NodeJs but the PHP SDK. I just migrated to 3.2 and find either stuff has changed what has changed is not always documented. For example in 2.x you could get stuff via $result->metrics[‘resultCount’]. Now in 3.2 it has changed but there is nothing in the section on how to access the metrics data which is now under the meta object.