CODEWITHSUNDEEP
couchdbpouchdbnosql
Raphael Rafatpanah
Raphael Rafatpanah

Reputation: 20007

Best practices for _id in PouchDB / CouchDB

TL;DR: If one chooses to use fields like address and lastname in the _id of a document, how do you handle updates to address and lastname in a way that scales in a multi-device, sometimes offline environment.

I am looking for best practices when using fields in a document's _id that may change in the future. For example, address and/or lastname. Not only can a customer's address change, but what if a user entered the wrong address by mistake? What if the mistake was not found until after the document has been replicated across devices and updated on more than one device?

Is there a way to handle updates to _ids? For example, creating an entirely new document with a new _id and removing the old one? But does that scale in a multi-device, sometimes offline world?

For example:

{
  "_id": "Jane-Smith",
  "address": "44 street, Boston, MA 93999",
  "telephone": "8888888888"
}

To handle the case that there are multiple customers with the same name, would it make sense to use add something to the customer name?

{
  "_id": "Jane-Smith-7ae78c",
  "address": "44 street, Boston, MA 93999",
  "telephone": "8888888888"
}

Pros:

  1. Saves space
  2. Since _id is the primary key, searches using _id are faster

Cons:

  1. What if properties used in _id change? Searches would be performed on stale data. If you create a new document with the updated _id, what are the implementations across synced databases that may have made offline changes?

Update:

This article was helpful:

https://davidcaylor.com/2012/05/26/can-i-see-your-id-please-the-importance-of-couchdb-record-ids/

I did not realize that _ids could be composed of address and lastname. However, what if a customer's address and/or name changes?

I am trying to wrap my head around the right way to store customer data in PouchDB / CouchDB.

Upvotes: 1

Views: 1750

Answers (1)

nlawson
nlawson

Reputation: 11620

If your id contains information that is frequently changing, then it's best just not to store that information in the id. The optimization to pack as much user information as possible into ids is a good one, but it breaks down if that information ever changes, because once the id changes you can't really track changes to that document anymore because it effectively becomes a new document.

In your case you should probably make the id something else (random, even) and then use mapreduce/pouchdb-find for querying.

Upvotes: 8

Related Questions