Id property is different for same document if using create or find

[janober]

Not sure if that is on purpose but the document id value I get when creating and finding the same document is different.

If I for example create a new Test document the id property is an object:

{ id: 
   { cas: 
      { '0': 236126208,
        '1': 179461631 },
     id: 'testId',
     docType: 'Test' },
  name: 'This is the name' }

but if I then query it I get what I would have expected:

{ docType: 'Test',
  id: 'testId',
  name: 'This is the name' }

I would say it should always return the id as a string and not an object.

[janober]

After looking a little bit in the code it does not look like intended. It looks like it sets the data on the object that gets returned directly but somehow that object (which should contain the whole data) ends up to be just the "id" property. Tried to fix it but do not really understand at all what is going on. Code should work fine as it is.

It looks like that there is something between the callback function which is given to "Test.create" and what gets returned to the callback function in "CouchbaseDB.prototype.create".

[nolandubeau]

Couchbase does this by default, even with the native sdk. the CAS values
have something to do with the versioning of the object I believe. I will
need to see if we can change what is returned, but if this is what the
default couchbase module does then I would be hesitant to change what is
returned.

On Wed, Jan 28, 2015 at 5:41 PM, Jan [email protected] wrote:

After looking a little bit in the code it does not look like intended. It
looks like it sets the data on the object that gets returned directly but
somehow that object (which should contain the whole data) ends up to be
just the "id" property. Tried to fix it but do not really understand at all
what is going on. Code should work fine as it is.

It looks like that there is something between the callback function which
is given to "Test.create" and what gets returned to the callback function
in "CouchbaseDB.prototype.create".

—
Reply to this email directly or view it on GitHub
#8 (comment)
.

_Nolan Dubeau_VP, Engineering, Guardly Corp.
Online: https://www.guardly.com
LinkedIn: http://www.linkedin.com/in/nolandubeau
20 Maud Street, Suite 307, Toronto, ON M5V 2M5
CA (416) 434-8029 | US (650) 262-3599 | Skype: nolandubeau
Please consider the environment before printing this email.

[janober]

Hm but even then I would say that it should be consistent. Either it should always just return the id or always that Object. Having to always fix the documents in the app does not sounds like a good idea to me, think the connector should take care about that.
Another issue is that it is inconsitent to how the other connectors work (ok, at least I think because I just have used the Memory & MongoDB one till now). And they always return a value and never an Object. That means that if somebody wants to switch to Couchbase, this would be one more change to do and considering all the other problems that will probably occur anyway any easily avoidable problem should probably be avoided.

One other inconsistency is the "docType" which is once part of the id (create) and once of the document data (find). Also that should probably be the same.

As a work around I changed in my local version the callback in "CouchbaseDB.prototype.create" from:

callback(err,result);

to

callback(err,result.id);

This fixes at least the problem with the id but not the docType. And to be honest because the result is actually just the "id" I have currently not the slightest idea how we could fix that.

Ah yes the CAS gets changed whenever the document changes for optimistic locking. So I can read the document, change something and write it back. It can then compare the CAS value and only writes it if they match. If they are different it means the value has changed inbetween and the chance that something would be overwritten is quite high (or almost certain). So I guess that is something the connector should take care about and the loopback application does not have to care about at all. Only then when I write something and the CAS does not match. In that case the connector should probably return an error that the document has changed in the meantime and then the loopback application has to handle that.
So do not think that anybody will ever need the CAS value in the loopback application itself. However if they would need it, then they would probably not just need it when a new document gets created, also when it already exists. So meaning that if I am totally wrong there, it should at least be again consistent that both times the id with the CAS gets returned.

[janober]

Sorry take back the the last few sentences. Was stupid, did not think that through at all. It is true that the cas is not "directly" needed in the application itself but it has to get passed through back to the save because the connector can not really cache it or anything like that. So created issue #10 that the cas always gets returned but not as part of the id.