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)?

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?