Typo in README example
ismyrnow opened this issue · comments
In the README example, it seem like the first db.post call is returning an object with an id, and not an _id, like the other api calls.
Promise.resolve().then(function () {
return db.post({
name: 'tomato',
uses: ['tomato juice']
})
})
.then(function (res) {
console.log(res) /* {ok: true, id: 'xwkfi23syw'} */
...Shouldn't that id be _id on the last line quoted there?
It seems like the one with the underscore is out of place, since that one only appears once, while the regular one appears in the beginning and end.
Ok, I take that back, looks like db.get returns the document, which had the id inserted as _id, but the other methods manual set id.. so yeah a bit of inconsistency in the code.
This is on purpose.
It means that when you save you know what was the id assigned to the document. This comes naturally as an .id attribute, which makes sense since in our table there's a column called id. At the same time any document has an _id field embedded. This is better, because people can use their own ids, but it is unlike that they will have a field called _id, the underscore works as a protection for the field.
This is inspired by CouchDB's document methods.
Is there a better way to do it? Do you think it would make more sense to return ._id from .post methods, instead of .id? Why?
Thanks for the couchdb reference. I think keeping the API similar to that makes a lot of sense, and the behavior does as well, now that it's clarified.
If I have questions about the reasoning behind it, or edge case behavior (e.g. can you specify a non-unique attribute called id), I'll take it up with the couchdb folks.
no, no! this project is not affiliated with CouchDB, it was just an inspiration!
I know you didn't say that, but anyway if you go to the CouchDB folks and ask them why, on pgjson, the objects have an ._id but the API returns an .id, they will reply "what is pgjson?".
Lol, I totally understand. I've used couchdb in the past, and am passingly familiar with the API, and the practice of _id being the unique id, and being auto generated by default. I've been using postgres for the past few years, and saw this library as a way of enabling couchdb like behavior without new db technology in the stack at work.
That said, any questing is purely for my own benefit. The couchdb folks are smart, so I suspect there is a good reason for accepting an _id and returning an id. And I totally understand the relation between this project, postgres (underlying storage), and couchdb (api inspiration).