Issue with HttpClient.prototype.exists and secondary indexes

[accelerated]

When using HttpClient.prototype.exists with secondary indexes instead of keys such as

db.exists('mybucket', null, { links: [{tag: 'mytag', bucket: 'mybucket', key: 'mykey'}]}, callback}

it return exists == true even if there are no objects with such links. The reason is that riak returns HTTP 200 with empty array of keys but since code only looks for 401 return code, it mistakenly thinks that the object exists, which is false. Code should check the length or returned key array. So in the case where key == null and object.links is set, (i.e. the user passes a secondary index), perhaps a regular link walk should be done instead or a GET which would return the link list, while maintaining transparency for users.

[roidrage]

Just to clarify, this is actually about links rather than secondary indexes, or do you see similar behaviour when calling exists with 2i query?

[accelerated]

Hi, yes with links. I think I made a mistake by saying secondary indexes. :)

[roidrage]

The use case here would be to verify if the object the link points to exists?

[accelerated]

Correct. And I think it would be useful to have this with 2i as well. The use case is that you want to check existence of objects in DB without incurring the penalty of querying the entire object. Not sure if it's possible to do with links/2i indices? If it is, it should be bundled in the same API call.

[roidrage]

It could be doable with secondary indexes, as a query only returns a list of keys.

With links, though, while you can trigger HEAD requests, it doesn't include any indication of whether or not there is a payload included that lists Riak objects or if the list is empty.

[accelerated]

Agreed. Well if you could implement support for 2i it would be great!! Thanks!