These are chat archives for Automattic/mongoose

7th
Nov 2015
Imanol Yáñez Sastre
@bordemof
Nov 07 2015 19:38
Anyone knows why a model.count works but model.find doest?
Mongoose: items.count({}) {} this works
Mongoose: items.find({}) { fields: undefined }
this doesnt
Paul Marbach
@fastfrwrd
Nov 07 2015 19:59
I'm attempting to unit test some pre-save middleware without mongoose.connect()-ing. model.save() ends up just hanging. Any pointers on a simple point at which I could spoof that using sinon or similar?
Mike Vercoelen
@mikevercoelen
Nov 07 2015 20:21
Could someone advise me: what a good / scalable model for "one on one" messaging would be? so NO multiple receivers
"schema design"*
Imanol Yáñez Sastre
@bordemof
Nov 07 2015 20:27
What are your needs of messaging?
Mike Vercoelen
@mikevercoelen
Nov 07 2015 20:28
I got a users collection + messageCount, which is the notification counter for a new message
a message: date, message, receiver (id, name, photo), owner (id, name, photo)
only one on one messages, so no multiple receivers
must be scalable, prob more read than write
Imanol Yáñez Sastre
@bordemof
Nov 07 2015 20:33
name and photo in every owner and receiver is to avoid population?
Mike Vercoelen
@mikevercoelen
Nov 07 2015 20:34
ye, don’t know if thats a good idea?
but I thought it would be better performance
Imanol Yáñez Sastre
@bordemof
Nov 07 2015 20:35
It deppends a lot in how you perform and structure your queries i think
Mike Vercoelen
@mikevercoelen
Nov 07 2015 20:35
well: we create a new message, and we get a message list, that’s it
Imanol Yáñez Sastre
@bordemof
Nov 07 2015 20:35
Correct me if im mistaken
but the receiver info (photo and name)
you already have it
Mike Vercoelen
@mikevercoelen
Nov 07 2015 20:36
true that
lol
Imanol Yáñez Sastre
@bordemof
Nov 07 2015 20:36
Or at least its an additiona query for every conversation
Mike Vercoelen
@mikevercoelen
Nov 07 2015 20:37
ur right, lol
Imanol Yáñez Sastre
@bordemof
Nov 07 2015 20:37
I mean If you already dont have it
Mike Vercoelen
@mikevercoelen
Nov 07 2015 20:37
nope, I already have it oke thats cool
Imanol Yáñez Sastre
@bordemof
Nov 07 2015 20:38
Your solution would be more usefull when a conversation with n different participants
Mike Vercoelen
@mikevercoelen
Nov 07 2015 20:38
yep, so what do you think would be the most simple / scalable solution?
would you put messages directly in the users collection?
would you have a separated “inbox” collection?
Imanol Yáñez Sastre
@bordemof
Nov 07 2015 20:39
Personally a prefer the separate collection
I understand the cost of accessing to a different collection
Mike Vercoelen
@mikevercoelen
Nov 07 2015 20:40
yep m2: because of sepration of concerns and cost
yep
Imanol Yáñez Sastre
@bordemof
Nov 07 2015 20:42
Mi aproach i think it would be something like: message collection: message(owner:(id),receiver:(id), text,created_at)
and something like read:true/false i think its usefull too
and limit the query to unread messages, limit to a default number or by date
If you prefer to avoid message owner population you could store avatar and name too, i think it depends on the situation
Mike Vercoelen
@mikevercoelen
Nov 07 2015 20:47
well downside of populating: if users update their profile picture / name, its gonna be pretty heavy to update all the users, so I think populating might be a smarter choice. In my application the profile picture / display name can change easily
downside of not populating*
so something like this:
?
Imanol Yáñez Sastre
@bordemof
Nov 07 2015 20:52
Yeah i think thats the way i would choose
Mike Vercoelen
@mikevercoelen
Nov 07 2015 20:52
dude, thanks so much man :)
Imanol Yáñez Sastre
@bordemof
Nov 07 2015 20:52
Avoid a lot of data storage, and if the performance its someday a problem
there are aproaches to solve heavy populations
caching, indexing or something like that
:+1:
Mike Vercoelen
@mikevercoelen
Nov 07 2015 22:07
@bordemof u still there :) ?