I would like to know if in Mongo it is possible to create an index on embedded fields without using dot notation and how to do it. Our client is asking for this other option but we can't find any reference in the official documentation (unless we are mistaken).
Has anyone done it before? Any advice on this topic?
Thank you very much,
Irene.
Related
I discovered one of my mongodb documents has duplicate fields with the same key.
I also realize this is supported by mongoDB (as per MongoDB Documentation)
I'm wondering if anyone knows how to properly query to diagnose the scope of such an issue.
And if anyone has any insight into possible root causes when working in Javascript that'd be nice too.
How can I determine what collection a Mongo document belongs to?
I'm using MeteorJS, but even if you don't use this, I'm pretty sure I have access to MongoDB's internal commands so please answer anyways.
Happy to close if this is a duplicate, but I didn't find anything close to this.
There isn't a real short command but to cycle through each collection and query for the field, or fields that uniquely identifies this document. Don't know MeteorJS but if you are looking for just a quick way to get the data to find out and not add a program function you can download RoboMongo. Think of it as SQL Management Studio for MongoDB. If you are looking for a program function to do this then I suggest you make it a jscript function you create inside MongoDB (similar to stored procedures) to do the work and return the results to you when done.
Are you querying the document now and wondering where it is coming from? If so, it should be in the code.
I am still new on the whole area of MongoDB systems.
I was wondering whether anyone of you knows if MongoDB is declarative or navigational when it comes to accessing objects within a document?
What I mean is:
-> Declarative: a pattern is given and the system works out the result. In other words, it works in the same way as SPJ queries
-> Navigational: it always starts from the beginning of a document and continues from there
SPJ (Select-Project-Join) is more than just accession of documents/rows, it is the entire process of forming a result set for queries.
I am unsure how the two: "Declarative" and "Navigational" are compatible. You talk about "Declarative" being the formation of a result set but then "Navigational" being related to accessing a document, i.e. reading the beginning of it.
I will answer what I believe your question to be about, the access patterns of documents.
I believe MongoDB leaves reading up to the OS itself (might use some C++ library to do its work for it) as such it starts from the beginning of a pointer (i.e. "Navigational") however, as to how it actually reads document does not really matter.
Here is why, MongoDB does not split a document up into many pieces to be stored on the hard disk, instead it stores a document as a single "block" of space. So I am going to turn around and say you probably need to look at the code to be sure exactly how it reads, though I don't see the point and here is a presentation that will help you understand more about the internals of MongoDB: http://www.mongodb.com/presentations/storage-engine-internals
Bear with me as I'm pretty new to MongoDB and mongoose has been my only interaction with it. So apologize ahead of time if I'm not properly separating the two technologies or understanding either.
I have a collection that is basically a log. Each log item is the result of a status check on a specific server that I have in my system. When I delete a server I'd like to also remove all the associated log entries. Whats the most efficient way to do this? I know I can find all the log items with a specific server id then iterate through each and remove it but that seems really inefficient. I've read through most of the mongo documentation and it looks like findAndModify is the best way to do this but I can't figure out syntax for this with mongoose. Any chance someone could help me out?
I'm using the latest version on mongoose at the moment, 1.7.2
Maybe I'm missing something here, but why not just do
db.logs.remove({serverid: deletedServerId})
?
The documents in my database have names and descriptions among other fields. I would like to allow the users to search for those documents by providing some keywords. The keywords should be used to lookup in both the name and the description field. I've read the mongoDB documentation on full text search and it looks really nice and easy if I want to search for keywords in the name field of my documents. However, the description field contains free form text and can take up to 2000 characters, so potentially there are a few hundred words per document. I could treat them the same way as names and just split the whole description into separate words and store it as another tag-like array (as per the Mongo example), but it seems like a terrible idea - each document's size could be almost doubled, plus there are characters like dots, commas, etc.
I know there are specialized solutions for exactly this kind of problems and I was just looking at Lucene.Net, I also saw Solr mentioned here and there.
Should I be looking to implement this search feature in mongoDB or should I use a specialized solution? Currently I just have one instance of mongod and one instance of a web server. We might need to scale later, but for now that is all I use. I'd appreciate any suggestions on how to implement this feature.
If storing the text split out into an array per the documented approach is not viable (I can understand your concerns), then I think you should look into a specialised solution.
Quote from the MongoDB documentation:
MongoDB has interesting functionality
that makes certain search functions
easy. That said, it is not a dedicated
full text search engine.
So, for more advanced full text search functionality I think a dedicated engine would be more suited. I have no experience in this area so I can't offer much in the way of suggestions from here, other than what my thoughts would be if I was in the same boat:
how much work involved in using a dedicated full-text search engine instead of MongoDB's functionality?
does that add more complexity / is it worth it?
would it be quicker/simpler to use MongoDB and just take the hit on the extra disk space?
maybe MongoDB will support better full-text functionality in future (it is rapidly evolving after all)
Fulltext search support is planned for the future. However right now you have to go with Solr & friends. Using the built-in "fulltext" functionality is not really suitable for real world usage.