I need to have a page with common settings for my web-app, and using mongodb as my database.
I am planning to just create this collection with only one document. it will always have one document.
Is there a way to create one document by default in some way? and then just edit it from UI?
Or I should create one document from UI itself and then keep editing it?
If I use config file then user won't have flexibility of changing the value as they need.
Please share if you have better suggestion.
You can certainly have a collection with a single document in it.
Is there a way to create one document by default in some way?
You can insert the document with default values, if there isn't already a document in the collection, when your application starts.
Related
I am aware that MongoDB will dynamically create a collection when you attempt to insert a document into a non-existent collection. My question is:
How do I set up default options so that the collection has the options I want when it is dynamically created?
I don't think you can do that. Your options are:
Pre-create the collections if the pattern is dynamic yet predictable.
List the existing collections before inserting and create the new collection yourself with the right options if it's not already present.
Do not use dynamic collections but rather put the dynamic part as a property to individual documents in a shared collection.
I chose to write a wrapper around mongoc_database_get_collection(). There is a little bit of additional overhead for an extra round trip request to the mongo server to see if the collection already exists. If not, the wrapper creates it with the options I want and returns the new collection. If the collection already exists, the wrapper returns the existing collection.
I want to manage multiple projects data in mongoDB. Each project contains multiple users from multiple departments with multiple role assigned to them. plus certain task is assigned to each user. Now I am confused about schema, not able to decide which entity should be kept as collection & which one as document ? What is the best efficient way to store ?
should I keep all under single collection as embedded documents or in separate collection ?
Thanks
First of all if you are using mongodb you should know why are you using it. MongoDB is not about normalize stuff. If you are able to create data structure is de-normalize way then and only then go for MongoDB.
I think you should maintain one single document containing all the mentioned things above. But the scenario which you have mentioned above is good for relational database. you need only 3 entities in relational database and your problem is solved.
Still if you want to go for mongodb you can go with one collection only. which contains project details number of users working there and their roles and department.
I have a MEAN database application with a number of Mongo collections with hierarchical relationships via ObjectId. A copy of the application works locally offline, and another copy runs on the production server.
The data contain collectively describe rules and content that drive a complex process. These data need to be entered offline so that these processes can be tested before the data go into the production environment.
What I assumed I would be able to easily do is to export selected documents as JSON, then relatively simply import them into the production database. So, the system would have a big "Export" button that would take the current document and all subdocuments and related documents, and export them as a single JSON file. Then, my "Import" button would parse that JSON file on the production server.
So, exporting is no problem. Did that in a couple of hours.
But, I quickly found that when I import a document, its _id field value is not preserved. This breaks relationships, obviously.
I have considered writing parsing routines that preserved these relationships by programmatically setting ObjectIds in parent documents after the child documents have been saved. This will be a huge headache though.
I'm hoping there is either:
a) ... and easy way to import a JSON document with _id fields intact, or ...
b) ... another way to accomplish this entirely that is easier than I am making it.
I appreciate any advice.
There's always got to be someone that doesn't know the answer who complains about the question. The question is clear and the problem is familiar.
Indeed, Mongoose will overwrite any value you provide for _id when you create a document either via the create() method or using the constructor (var thing = new Thing()).
Also, mongoexport/mongoimport will not fill the need to do this programmatically, at least not easily.
If I'm understanding correctly, you want to export a subset of documents, along with any related documents, keeping references intact. Then, you want to import this data into a remote system, again, keeping references intact.
The approach you took would work just fine except it will destroy all references, as you found out.
I've worked on a similar problem and I believe that the best way to do this is to do what it sounds like you wanted to avoid. That is, you'll iterate over your collections and let Mongo generate its _ids as it will. Add your child documents first, then set the references correctly in your parent documents. I really don't think there is a better way that still gives you granular control.
In current version of mongodb you can use db.copyDatabase(). Start current instance of mongodb where you want to copy database and run following command:
db.copyDatabase(fromDB, toDB).
For more options and details refer to db.copyDatabase()
In Zend_Service_Solr I can add or delete a record.
$solr->addDocument($document);
Is there any way that I can update a record. I couldn't find any document for that. Or is there any extension for doing the same.
In most cases updating a document in Solr is to add the same document again (with the same value for the uniqueKey field).
It's possible to perform certain updates in more recent versions of Solr, but these require all fields to be stored (so that the document can just be re-added internally) and a custom update syntax. There are also some work in progress with non-textual DocValues being updatable without having to resubmit the complete document, but this is currently not in any released version of Solr.
The best way to handle this is usually to just re-submit the document with updated values, and have a straight forward way of doing that in your application code.
In the project I've been working on, I've added a new field - an embedded document. Will this addition affect data prior to the change? From what I've read this shouldn't affect prior data, and this is actually one of the benefits of using MongoDB. Its just the previous data won't have that field.
Thanks!
No it won't affect your previous documents - each document in your collection can have it's own unique fields if you want. It is up to you to handle this at application level.