We have a couch DB we are developing on. We have a script that, for development purposes, just recreates the couch database from some json files from scratch every time we run that script. All the data we are inserting into couch from this script have unique _id's within all of the databases/documents.
The problem is, after we run this script, the pouch database in the browser starts creating duplicates when it synchronizes with couch. This results in duplicate data both in pouch and couch because when pouch replicates back to couch, couch will now contain duplicate data too.
Does anyone know if there any way or method to prevent this duplication from occurring? It was my understanding the _id field was suppose to be unique, but that's clearly not the case, because both couch and pouch are creating duplicate records with the same _id fields.
Related
Writing REST API using Nodejs and database is mongodb 3.6.
Collections Names : Subscription, Users and Offering
I am using aggregate function to fetch data from subscription and using lookup I am fetching user which has subscribed.
What I want is in the same output (previous line) I also want to list all the records from offering collection as array.
How do I can get it.
Thanks in advance.
I don't think you can, and neither you should. Getting all records of some collection is bad practice, always try to limit yourself with only things you need.
If you really want to add resutls from some totally unrelated collection then you should make separate request and then add them together in json you sending to client.
I am using nodejs, Mongoose and mongodb database.
Sometimes I have seen that if I drop a database that included some collections inside it, when I run my node which makes some collections inside the database ( with the same name ), then the information that I want to save as a new entity does not show correctly.
I need to also mention when I drop the database in mongo db shell I also manually delete all the catch files inside c:/data/db ( default mongo db folder).
I checked the mongo documentation, sometimes it could make a problem if you make a database with the same name of the deleted database. Located at https://docs.mongodb.com/manual/reference/method/db.dropDatabase/#db.dropDatabase
You answered your own question. The document you have linked describe the solution:
Warning: If you drop a database and create a new database with the same name, you must either restart all mongos instances, or use the flushRouterConfig command on all mongos instances before reading or writing to that database. This action ensures that the mongos instances refresh their metadata cache, including the location of the primary shard for the new database. Otherwise, the mongos may miss data on reads and may write data to a wrong shard.
I want to get all documents inside a CouchDB database and then listen to changes on that database. I could:
1- Get the docs using the _all_docs view. /db/_all_docs
2- Get the current db update_seq. /db .
3- listen to the changes in the database. /db/_changes?since=update_seq
But what if one or more documents are created right after I query the _all_docs view and before I get the update_seq? If that happens when I listen to the changes which happened after the update_seq I'll never receive those documents.
Is there a way to know what was the DB's update_seq when a given document had a given revision? With that, I could be 100% sure I'll never miss a document.
Add update_seq=true to your request for _all_docs, you'll get the update_seq for the database at that time. (this avoids the race condition you are afraid of)
In the TAMA implementation, I came across an issue with Couchdb. (Version 1.2.0) ,
We are using named documents to maintain unique constraint logic in the application. (named documents : whose _id is user defined, and not couch generated.)
We are using the REST API to add the documents to Couchdb, where we found strange behavior :
When we try to recreate the documents using HTTP PUT which have been deleted in the past(because of bug in the code), the documents are not created the first time .
HTTP Put - Returns HTTP 200, but doc is not saved in couchdb.
Again trying the same request,
HTTP Put - Returns HTTP 200 and adds the doc in database.
HTTP PUT request needs to be sent twice to create and save the doc.
I have checked that the above bug is reproducible for deleted docs, i.e the response for GET _id is {"error":"not_found","reason":"deleted"}.
This looks like a bug in CouchDB to me, could you please let us know if you could think of any scenario where above error might occur and any possible workarounds/solutions ?
Couchdb has a builtin mechanism to ensure that you do not overwrite the same document as someone else.
If you PUT any existing document, you'll have to accompany this process with the current doc._rev value, so that couchdb can confirm the document you are updating is based on the most recent version in the database.
I've not come across this case with deletions, but it makes sense to me that couchdb should not allow you to overwrite a deleted document as the assumption should be, you just don't know about the deletion.
Have you tried if you can access the revision of the deleted document and if so, whether by adding it to the new document, you can succeed with the PUT on the first call?
I'm building a chat server app using node.js.
I need to save chat transcripts on the database and would like
to play with nosql database like mongodb. If i was in relational db world, i would
create users, chat_sessions and chat_messages tables and, for every new message, i'd
append new record in chat_messages table.
Which is the best approach in nosql?
Do i have to create a chat_session document and, inside of it, create
a chat_messages structure that is updated for every new message or
is there a better way to do it for nosql/mongodb?
You would use a similar approach and insert each new message as a separate document into the collection (possibly one for each room or channel).
Documents in MongoDB have a 16mb limit so storing the entire history in one document, which grows in an unbounded fashion, would be a bad choice.
You can de-normalize usernames and store them on the messages themselves to avoid querying two tables (this would likely be a join in a relational database).
It may make sense to split the data into multiple databases rather than collections (per room, channel, whatever) because currently mongodb has a database level write lock. This would allow you to achieve greater write concurrency with mongodb and node.js.