I checked the API http://mongoosejs.com/docs/populate.html and tried out. It seems that populate
can only works on foreign _id
. Even there is a match
option, it just add more filtering condition on _id
query condition. There is no way to just populate with fields not involved with _id
.
In my project, we keep the _id
as ObjectId and has another field as auto-increment Number. For example, customers
model has _id
as Object and cuid
as incremental number. Other collections just reference to cuid
not to _id
.
Is would be great to be able to customize this?
Is there any design limitation causing this feature missing?
It would be great to be able to customize this, but right now we enforce _id
. I can't think of a good reason off the top of my head why not though. I'll have to investigate further.
The ability to populate not just on a single other field but even on a set of fields is almost required to properly support sharding, which is a huge use case for us.
For example, we have a collection "students" which may have a shard key for "subscription"; when we populate student data from our sections model (which contains an array of students) we have the subscription on the document but it will only look up based on the _id stored in "student" rather than allowing us to specify that it should also map the documents "assignment" field to "assignment" on the student.
Since we'd then be doing a lookup without the shard key when doing populate it renders sharding useless, requiring all shards to be hit to retrieve the data instead of just one.
This is something we would be willing to fund development for or even do ourselves if we could get some guidance of where to do the work. It is a major need for our company (GradeCam).
@taxilian are you setting the shardKey
schema option? AFAIK that's what that option is for.
I haven't actually moved to start doing it yet because I've been looking for a solution to this issue; does populate take into account shardKey? My understanding was that shardKey only affected updates and inserts
It would be great to be able to specify the field which is to be "joined by", for example I'd like to be able to populate not only by userId (i.e. _id) field but also by userType, userGroup etc.
Thanks!
+1
+1 would be very useful
+1 same here!
+1 love to have this
+1
+1
+1
It would be especially nice to be able to select the variable you would like to populate with by adding a parameter such as key
:
For example if had posts that I wanted to populate the author
and comments
parameters of, but the parameters are holding non ObjectId parameters (username of user and title of comments) before population:
{
author: "user1",
comments:["comment5", "comment6"],
title:"Post1"
}
It would be nice to be able to add a parameter like "key" to let mongo know which parameter to lookup by:
Posts.find().populate([{path:"author", model:"Users", key:"username"}, {path:"comments", model:"Comments", key:"title"}])
This would fill the author
parameter with a User found by username as well as fill the comments
parameter with comments found by their title (I realize the comments by title is a little unrealistic, but you get the point).
+1
+1
+1
+1
+1
+1
+1
Big agree. I'd love the ability to define custom population schemes. It'd be great for any schema with one or more fields that are file paths, allowing populate to read from storage.
+1
+1
+1
+1
+1
+1
+1
+1
+1
+1
+1
+1
+1
+1
+1
+1
+1
+1
+1
+1
+1
+1
+1
+1
+1
+1
+1
+1
Try this code: https://github.com/alexmingoia/mongoose-populate-virtuals.
Actually, any reason for not merging Alex's code into main repo and make this a core feature?
@rturk I really really like that plugin, thanks for pointing it out. @alexmingoia what are your thoughts re: merging your module into mongoose core? The idea of using virtuals to handle more generic populate (without having an actual field persisted to the db) is really powerful.
That would be ideal. It'd be much better in core because it overloads Query.prototype.populate
and other core functionality.
The only thing blocking me from creating a pull request is that there's little to no test coverage, and documentation is lacking. I am using it in production in multiple scenarios and it's stable, but I think if someone were to write a test suite it might expose some minor issues or idiosyncrasies that need to be documented.
Is someone willing to tackle the test suite? If not - I can do it but don't expect that to land before next month.
I'll take a look. I've been meaning to rewrite populate anyway :)
Ping me on IRC (freenode, amingoia
) or gitter if you have any questions about the code.
https://github.com/whitecolor/mongoose-fill also does a great job to populate using data from other models
+1
+1
+1
this is a must :)
+1
+1
+1
+1
+1
+1
+1
+1
+1
+1
+1
+1
+1
+1
+1
+1
+1
+1
+1
+1
+1
+3
+1
Most helpful comment
@rturk I really really like that plugin, thanks for pointing it out. @alexmingoia what are your thoughts re: merging your module into mongoose core? The idea of using virtuals to handle more generic populate (without having an actual field persisted to the db) is really powerful.