don't have it `include` itself dynamically into other classes after the
fact. this doesn't change any app behavior, but it does mostly fix the
selinimum autoload tracking in the selenium post-merge build
a recent plugin change made ConversationParticipant (and others) no longer
need to get required at startup time. so when selinimum's autoload
extensions would hide the constant and its dependencies (ModelCache) at the
end of a spec, User's add_to_caches after_create hook could go 💥 in a
subsequent spec since ModelCache was no longer in the module tree... iow,
if ModelCache is not explicitly loaded along with User, selinimum has no
way of knowing it's a dependency and will not restore it
test plan: specs
Change-Id: I8daa8b9ef5f9d7ab7ffae77a987f1b339865ea47
Reviewed-on: https://gerrit.instructure.com/102586
Tested-by: Jenkins
Reviewed-by: Landon Wilkins <lwilkins@instructure.com>
Product-Review: Landon Wilkins <lwilkins@instructure.com>
QA-Review: Landon Wilkins <lwilkins@instructure.com>
Change-Id: Id1900160375644ea33badaa9d9f9185fab6b81ac
Reviewed-on: https://gerrit.instructure.com/92726
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins
Product-Review: James Williams <jamesw@instructure.com>
QA-Review: James Williams <jamesw@instructure.com>
refs #CNVS-26056
Change-Id: I4a4d91c8f96a9d86646bdd14ba9ed75e365a9764
Reviewed-on: https://gerrit.instructure.com/69227
Tested-by: Jenkins
Reviewed-by: Cody Cutrer <cody@instructure.com>
Product-Review: James Williams <jamesw@instructure.com>
QA-Review: James Williams <jamesw@instructure.com>
they were broken in rails4 because the original non-cached
method (e.g. "find_by_id") would define itself the first
time it went through the method_missing mess, undoing
all the ModelCache overrides
turns out we weren't using them anyway
refs #CNVS-21596
Change-Id: Ibd4b9c14f1312d2218420fde107ce6278d45c465
Reviewed-on: https://gerrit.instructure.com/57933
Tested-by: Jenkins
Reviewed-by: Cody Cutrer <cody@instructure.com>
Product-Review: James Williams <jamesw@instructure.com>
QA-Review: James Williams <jamesw@instructure.com>
* gemfile tweaks
* removed ruby-debug (since it's broken in 1.9.3)
* removed colons from case statements
* turned off whiny nils for tests (they cause a 2X perf hit)
* added utf-8 encoding markers to files with multibyte chars
* removed an instance of calling String#map, which no longer works
* fixed an issue in the assets file where the yaml emitter doesn't output the
same whitespace as it did in 1.8.7
* fix call to .map without block
* fix yaml engine initialization for delayed jobs (was happening too late)
* fix rspec instafail
* fix UserProfile#id calls
* fix ModelCache for instance_methods now returning symbols
* fix user_spec collection not seeing the new objects
* fix course specs where POST lines are slightly different in 1.9
* fix utc_datetime in the time initializer
Change-Id: Ic95dda23cb910579e2828fb448323d4fc18902a2
Reviewed-on: https://gerrit.instructure.com/10705
Reviewed-by: Brian Palmer <brianp@instructure.com>
Tested-by: Zach Wily <zach@instructure.com>
various tweaks to speed up bulk message sending (~75% backend runtime
reduction, for both current and stale caches. ~55% frontend runtime
reduction. ymmv). highlights:
1. lots of preloading. some vanilla rails stuff, more hand-rolled.
2. conversation model hooks to reuse existing ruby objects if requested
(e.g. c.conversation_participants[0].conversation.equal?(c)
when done in a ModelCache.cache block).
3. more (and better) caching. some User# methods are now cached up to a
day (or until the user is touched).
4. various model tweaks to reduce redundant or unnecessary queries.
5. don't animate existing private conversations after the response
comes back. for bulk private messages going out to tons of existing
conversations, this would peg the client CPU and cause sadness.
6. defer delayed job creation
test plan:
1. run rails in production mode (so stream items and notifications
happen in delayed jobs, otherwise it's going to be *really* slow)
2. confirm that sending a bulk private message to a lot of people (e.g.
500) is faster
3. also confirm that nothing is broken :)
Change-Id: I92094f27ac51094a8047cb67f2cbb680a1839779
Reviewed-on: https://gerrit.instructure.com/9157
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
Cody Cutrer