Mongodb's dot notation feature is quite cool, but I find that it seems not work on referred documents.
So dot notation can only be used in embedded arrays or subdocuments, am I right?
Thank you.
Dot notation may only be used to query within the fields of a single document (or sub-document). It cannot be used to refer/query on other documents.
While there are times where I thought it would be an interesting feature to add, it's generally easy to create an alternative schema design that doesn't require it for "queryability" or performance.
Related
I Want to query using part of id to get all the matched documents. So I tried “starts with” and "contains" which works find but is there any performance issue for large collection?
The best way to make this search optimum :
Add $text index on the fields you want to do search in. This is really important because internally it tokenize your string to that you could search for a part of it.
Use regex which is also quicker to do.
If you are using aggregate, read this mongodb official doc about aggregation optimization which might help you to implement this in efficient manner : https://docs.mongodb.com/manual/core/aggregation-pipeline-optimization/
Last but not the least, if you are not yet fully inclined towards mongodb and project is fresh, look out for elasticsearch service which is based on Lucene. Its extremely powerful doing these kinds of searches.
The MongoDB docs for DBREFs say:
Unless you have a compelling reason to use DBRefs, use manual references instead.
Why? DBREFs seem more easy to use, since they encode the database and collection names, which would lead to less hard-coding in the application. Plus, DBREF is a standard format that many drivers understand.
This question is related, but not exactly the same:
MongoDB - is DBREF necessary?
The answer to that question is that embedding/denormalization is preferable to linking, but it doesn't answer the question of why manual linking is preferable to DBREFs.
Here a conclusion of all I viewed.
Using DBRef is not a join operation, it will automatically query the second or more times, depends on how much DBRef you have got in this collection fields.
Assuming you have a collection that its model has 10 DBRef, you make query for 10 elements' list of it and one of these DBRef is really needed. Once you query, Mongodb will runs 101(1 + 10*10) queries, automatically, no matter you need these DBRef or not. If you query these field manually, just a few coding and only 11(1 + 1*10) queries are needed.
So, what do you say?
I want to learn more about MongoDB's GridFS so I had a look at the manual.
It says:
files.aliases
Optional. An array of alias strings.
I know that this field may contain an array of strings, but what are the values inside this array used for? Alternative filenames?
Yes. For instance, from the MongoDB csharp driver source code (MongoGridFSFileInfo.cs, ln 474):
// copy all createOptions except Aliases (which are considered alternate filenames)
However, it's rather unclear what the semantics of this field are. The csharp driver, for instance, won't look for aliases when you search by name. As far as I can see, there's not even an index on aliases, so searching on that field is practically impossible.
In general, keep in mind that GridFS is a mere concept of how to store large files in MongoDB - the implementation isn't special in any way - it's just regular collections and conventions, plus the command line tools. While the general idea of GridFS is neat, it does come with a lot of assumptions and conventions that you might not want to deal with, and that can be painful to work with in statically typed languages. You can always build your own GridFS with a different fieldset, though.
I would really like to use the dot notation to create namespaces for my MongoDB collections' names.
For example:
users
users.admins
users.developers
Is this a bad idea ?
Are there any potential problems, drawbacks or limitations when doing this ?
There is nothing wrong with this. In fact, this book recommends the use of dot notation in collections on page 8. It refers to these as subcollections; however, that term doesn't seem to be in broad use.
It's important to realize that the 3 collections you've listed in your question are 3 distinct collections with no relationship to each other except for their naming. The dot notation does not do anything in terms of MongoDB functionality.
It is useful for organization though, and the collections list nicely when sorted alphabetically. So in summary there are no any drawbacks or potential problems and you gain an advantage as your collection names are better organized.
I've read everything I can find about Projection in MongoDB. I'm hoping this is simple and I just missed it due to the overwhelming flexibility of Mongo queries.
In our MySql database, we've adopted a business practice of having "hidden" fields be prefixed with an underscore. Our application knows how to hide these fields.
Moving some data to mongo, I need to retrieve the documents, with ALL underscore prefixed fields omitted. Of course this should be done in the query rather than document manipulation after retrieval.
All the operators like $regex, $in, $all seem to apply to values. I need to build a projection that ignores an unknown number of fields based on their name. Something like:
db.coll.find({}, {"_*": 0})
Of course that doesn't work, but explains the idea.
I should note: this is necessary because the documents are editable by our application users, so I have no idea what the schema might look like. I do know our "internal" fields are prefixed with an _, and those need to be protected by omission from the editor.
Hope it's easy...
You can have a separate field as hidden_fields or something. See the following schema.
{_id: 'myid1', hidden_fields: {"_foo": "bar", "_foo2": "bar2"}, key1: value1 ...}
Now on the basis of above schema just do,
db.collection.find({ ... }, {hidden_fields: 1})
This will display hidden fields. Also you can have indexes on fields within sub documents so no loss in terms of performance as well.
There is no functionality for this for good reason. It would be a nightmare to implement this kind of functionality and it would not scale nor would it be very fast.
The best way to do this currently is to set up a key-value store like:
{
fields: [
{k: "_ghhg", v: 5},
{k: "ghg", v: 6}
]
}
You would then $regex on the k field to understand which key names (fields) have underscore in them.
As a piece of advice I would highly recommend prefixed $regexs since they are way more effective at using the indexes you create, i.e. for the query you show: ^_*.
Moving some data to mongo, I need to retrieve the documents, with ALL underscore prefixed fields omitted. Of course this should be done in the query rather than document manipulation after retrieval.
I would personally do this client side, it will be 100x faster than database side.
As was mentioned by #Sammaye, MongoDB doesn't support this type of query in a natural/efficient way.
However, to optimize performance if you don't always need the internal data, I'd suggest you consider creating two documents, one with the always available data, and one with just the "_internal" fields. MongoDB will read and write less, and there will be less to manipulate on the client. This would be similar to having two tables in a RDBMS (one with public and one with private data).
This could make updates to the non-internal data simple as well by just updating the entire document (if possible in your scenario).
Of course, you could then also drop the extra "_" character as well, as that just adds extra unnecessary characters to the BSON data. :)