I have a Strongloop application using MongoDB. I have a model with several sub-models, using relations. When I try and insert an object into the database, only the top level data is added. All the related data is ignored. How do I get an entire object with sub-objects into the database?
See the embedded models documentation: http://docs.strongloop.com/display/public/LB/Embedded+models+and+relations
Related
Is there any way to create models from MongoDB Database like Loopback has model discovery to reverse engineer database schemas into model definitions.
Because mongoDB database model is flexible it is not possible or not practical to create data model from it. Let me explain it this way. In SQL we create tables and columns manually or programmatically which does not change overtime. On the other hand in mongoDB you do not need to create tables and fields, when you invoke insert function on mongodb the data is stored in document model structure, which can be change over time depending on the data submitted for the next insertion.
I have an application that uses mongo's oplog to follow insert, update and delete operations. I would like to get to full document through mongoose (populated), everytime one of the operations occur (findById with the id I get from the oplog), but I do not have the Schemas as there are defined in another application.
Do you think it is possible to get the full document without cloning the other application and registering each schemas for each model?
Thanks in advance!
Consider this picture:
The book says documents store database struggle with highly connected domains because "relationships between aggregates aren’t firstclass citizens in the data model, most aggregate stores furnish only the insides of aggregates with structure, in the form of nested maps.
".
And besides: "Instead, the application that uses the database must build relationships from these flat, disconnected data structures."
I'm sorry, I don't understand what does it mean. Why documents store database struggle with a context based on highly relationships?
Because document stores do not support joins. Each time you need to get more data it is a separate query. Instead, document stores support the idea of nesting data within documents.
I have a "project" entity and each project can have many "models" (files and some metadata) and each model is associated with a "user".
So far I have considered each of the entities as a document in MongoDB, However, I find myself going back to SQl style when trying to create the relationships between them (e.g. adding the project ID in each model's metadata). Is this okay in the NoSQL world? Should I have a nested document for project which contains a list of all linked models? If yes, how can I do that considering that I use GridFs for storing the model files, while the project is just a normal document?
In MongoDB your data model should be such that the most frequently accessed queries should be blazing fast. In this scenario , since you are using GridFS for storing model files, you can store project,user etc as metadata for a GridFS model entry. You can then query 'metadata' and GridFS together. You can refer to this for specifics : GRIDFS Metadata
I just started to use MongoDB and I'm confused to build object models with list property.
I have a User model related to Followers and Following object which are list of User IDs.
So I can think of some object model structures to represent the relation.
Embedded Document. Followers and Following are embedded to User model. In this way, a "current_user" object is generated in many web frameworks in every request, and it's an extra overhead to serialize/deserialize the Follower and Following list property since we seldom use these properties in most requests. We can exclude these properties when "current_user" is generated. However, we need to fetch full "current_user" object again before we do any updates to it.
Use Reference Property in User model. We can have Followers and Following object models themselves, not embedded, but save references to the User object.
Use Reference Property in Followers and Following models. We can save User ID in Follower and Following property for later queries.
There might be some other ways to do it, easier to use or better performance. And my question is:
What's the suggested way to design a model with some related list properties?
For folks coming from the SQL world (such as myself) one of the hardest things to learn about MongoDB is the new style of schema design. In the SQL world, everything goes into third normal form. Folks come to think that there is a single right way to design their schema, because there typically is one.
In the MongoDB world, there is no one best schema design. More accurately, in MongoDB schema design depends on how the application is going to access the data.
Here are the key questions that you need to have answered in order to design a good schema for MongoDB:
How much data do you have?
What are your most common operations? Will you be mostly inserting new data, updating existing data, or doing queries?
What are your most common queries?
What are your most common updates?
How many I/O operations do you expect per second?
Here's how these questions might play out if you are considering one-to-many object relationships.
In SQL you simply create a pair of master/detail tables with a primary key/foreign key relationship. In MongoDB, you have a number of choices: you can embed the data, you can create a linked relationship, you can duplicate and denormalize the data, or you can use a hybrid approach.
The correct approach would depend on a lot of details about the use case of your application.
Here are some good general references on MongoDB schema design.
MongoDB presentations:
http://www.10gen.com/presentations/mongosf2011/schemabasics
http://www.10gen.com/presentations/mongosv-2011/schema-design-by-example
http://www.10gen.com/presentations/mongosf2011/schemascale
http://www.10gen.com/presentations/MongoNYC-2012/Building-a-MongoDB-Power-Chat-Server
Here are a couple of books about MongoDB schema design that I think you would find useful:
http://www.manning.com/banker/ (MongoDB in Action)
http://shop.oreilly.com/product/0636920018391.do (Document Design for MongoDB)
Here are some sample schema designs:
http://docs.mongodb.org/manual/use-cases/
https://openshift.redhat.com/community/blogs/designing-mongodb-schemas-with-embedded-non-embedded-and-bucket-structures