github-starred/couchdb-best-practices

Fork 0

mirror of https://github.com/jo/couchdb-best-practices.git synced 2026-05-15 14:16:00 -06:00

[GH-ISSUE #56] How to handle unique Fields in Documents except _id #536

New issue

Open

opened 2026-04-14 22:00:44 -06:00 by gitea-mirror · 3 comments

gitea-mirror commented

2026-04-14 22:00:44 -06:00

Owner

Originally created by @h4cc on GitHub (Jul 8, 2015).
Original GitHub issue: https://github.com/jo/couchdb-best-practices/issues/56

Common case it to have unique Usernames/Emails in a document. How can be assured with couchdb, that the values of these fields stay unique?

A Idea i found interesting on stackoverflow, lets discuss the approach: http://stackoverflow.com/questions/1541239/unique-constraints-in-couchdb

Originally created by @h4cc on GitHub (Jul 8, 2015). Original GitHub issue: https://github.com/jo/couchdb-best-practices/issues/56 Common case it to have unique Usernames/Emails in a document. How can be assured with couchdb, that the values of these fields stay unique? A Idea i found interesting on stackoverflow, lets discuss the approach: http://stackoverflow.com/questions/1541239/unique-constraints-in-couchdb

gitea-mirror commented

2026-04-14 22:00:45 -06:00

Author

Owner

@jo commented on GitHub (Jul 9, 2015):

I also would have recommend the approach described in that stackoverflow answer but did not try it yet nor have thought about that method in depth.

Do you have a concrete use case?

@jo commented on GitHub (Jul 9, 2015): I also would have recommend the approach described in that stackoverflow answer but did not try it yet nor have thought about that method in depth. Do you have a concrete use case?

gitea-mirror commented

2026-04-14 22:00:46 -06:00

Author

Owner

@h4cc commented on GitHub (Jul 9, 2015):

Have not yet implemented any of these ideas. Will give feedback when i succeded, or failed...

@h4cc commented on GitHub (Jul 9, 2015): Have not yet implemented any of these ideas. Will give feedback when i succeded, or failed...

gitea-mirror commented

2026-04-14 22:00:46 -06:00

Author

Owner

@h4cc commented on GitHub (Jul 30, 2015):

Current state:

I tried having own documents for unique field, like unique usernames for user accounts.

It can be done using a user document containing {username: alice} and a view using emit(doc.username, null), but that would not guarantee uniqueness. If that does not need to be strongly enforced, it might be the easiest way to go.

A other implementation is using a "unique-doc" for that, like {_id: user-username-alice, username: alice, user_id: user-1234}. Having such a document per username can guarantee its uniqueness. To query by username then, could either be done doing two request to couchdb, like first GET /foo/user-username-alice and then GET /foo/user-1234. Or a view for the unique usernames doing a "JOIN" could be used like emit(doc.username, {_id: doc.user_id}), that would be reducing to a single query to a view.

What bothered me was having too much documents, whose only use was to ensure uniqueness or N-M relations. Is there a universal hint that says try to reduce the number of documents or rather try to reduce the number of changes to/size of existing ones?

@h4cc commented on GitHub (Jul 30, 2015): Current state: I tried having own documents for unique field, like unique usernames for user accounts. It can be done using a user document containing `{username: alice}` and a view using `emit(doc.username, null)`, but that would not guarantee uniqueness. If that does not need to be strongly enforced, it might be the easiest way to go. A other implementation is using a "unique-doc" for that, like `{_id: user-username-alice, username: alice, user_id: user-1234}`. Having such a document per username can guarantee its uniqueness. To query by username then, could either be done doing two request to couchdb, like first `GET /foo/user-username-alice` and then `GET /foo/user-1234`. Or a view for the unique usernames doing a "JOIN" could be used like `emit(doc.username, {_id: doc.user_id})`, that would be reducing to a single query to a view. What bothered me was having too much documents, whose only use was to ensure uniqueness or N-M relations. Is there a universal hint that says try to reduce the number of documents or rather try to reduce the number of changes to/size of existing ones?

No labels

pull-request

question

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/couchdb-best-practices#536

No description provided.

Rows
Columns