I've got a few cases where I need to relate data in other collections back to the original user. My current use case is storing "likes" of a post.
I thought of putting an array of post ids on the user object, but that whole thing doesn't need to come back when getting a user. Also considered an array of user id's on the post, but have a similar problem there.
Right now I'm trying out a separate "userLikes" collection that stores the user id and an array of the post id's they like. So the problem is that I get the username automatically on every request, but I can't store that as the identifier because it could change. I end up with an extra query just to get the user._id so I can check by that. It seems like un-needed overhead. I could send in the user_id with every request, but that also feels wrong since I'm already getting username automatically.
I can't pinpoint it, something just doesn't feel right about the implementation, although I can't currently come up with another good way. I assume others have had issues like this... how did you solve it (assuming my explanation of the problem was clear enough)?
about 7 years ago
You could use references to link the user collection with userLikes and optionally resolve the likes when they needs to come back when getting a user.
References are explained here - http://devcenter.kinvey.com/ios/guides/datastore#RelationalData
By "I get the username automatically on every request [but not the userId]" are you referring to the iOS library or Business Logic?