For cases where we don't need or want the responses on a thread at all,
like getting some metadata about a thread, we should be able to request
it without the responses. This exists in the ThreadPresenter but didn't
exist as an option that could be passed in the API call itself.
We've added this as an option now -- with_responses -- that defaults to
true, which preserves the existing behavior but does in fact allow
toggling.
This gives us a backwards-compatible upgrade path to allow changes to be
made the LMS so that requests which don't need the responses, or do need
the responses, can be explicit about what they want.
Use pluck instead of map for upvoted/downvoted IDs.
Mapping involves doing the projection locally, whereas plucking will ask
MongoDB to do the projection for us. This is the difference between
sending the whole document back and sending back the ObjectId itself.
Multipled against hundreds or thousands of documents, mapping can really
add up, so plucking should really help these 99%'ile cases.
Some of the ways comments are accessed in the User model (when a
complete user object is requested) lead to an N+1 situation because
while we preload the related documents (preloading the parent thread of
a given comment, in this case), further accesses to those comments
actually never take advantage of the preloaded relations.
We should be using the relation directly, which will still act the same
as before but allow us to actually benefit from preloading.
Now that MongoDB 3.0 seems to download/untar faster than 2.6, we seem to
be right over the line of how quickly ES can start up and be listening
for connections, which leads the tests to try and connect too quickly,
which fails.
By sleeping for 10 seconds after starting ElasticSearch, it's almost a
certainty it will be up and running by the time we try to first connect
to it.
Primarily, we wanted to reduce the one-thing-per-merge calls, but also,
we want to reduce allocations overall, both from merge calls which will
duplicate the source hash and from string constants sprinkled
throughout.
Seemingly, defining a constant-style word list is not the ticket. For
whatever reason, Ruby can't seem to figure out the list doesn't change,
and presumably is splating out all of the words and allocating them as
if they were declared right there. Wahhhh.
Now we're using a straight up one-for-one constant definition of each
string, in a big constants file, where we freeze the strings on the
spot. We then reference each constant directly at the callsite, which
was the original style and, ultimately, is the best for readability.
Robert Raposa
wajeeha-khalid
Calen Pennington
Toby Lawrence
Toby Lawrence
Tobias Macey