When we added rabbitmq usage within Tornado, we inadvertently caused
the Tornado ioloop to be initialized in runtornado.py's imports,
before we overwrote the _poll method. The end result was that we
weren't running the our instrumented Tornado poll function.
Fix this by moving that code to its own file which we import at the
top of runtornado.py, and adding comments documenting the situation so
we don't break this in some future import reorganization.
(imported from commit 016717476f10566fef4ed2b656f29f865d2084db)
Previously user_profile was a kwarg, which was inconsistent with all other
_backend functions.
(imported from commit 6b857bcb2c3c978079af2f6edd367c1804d51988)
This is to allow flexibility in functions that we think should be callable
via either GET or POST.
As part of this, POSTRequestMock was extended to populate the REQUEST
dict.
(imported from commit b9d32d2b65ff8a25885452992cf7dd37b9664246)
This includes a process_patch_as_post decorator which enables this view
to be invoked as a PATCH on an object.
Hopefully this decorator can go away once POST values are correctly parsed
in Django for PATCH verb invocations.
(imported from commit 6cf9d69cfb9dea5354ea37408566146757b5be54)
This slightly reduces code duplication and in the future the {api,json}_ methods
will hopefully go away, leaving only the _backend methods.
(imported from commit 82a6e4a2ff2ba5d272068e9ff043ea47a1a8d278)
Instead we now rely on the request._client value, which we were previously
passing along to s_m_b in all but one case.
For that one case, we just modify the Request object to include the value
beforehand.
(imported from commit 542f38f94bc447149cd4d2efaa5e8f48f756725b)
Addresses a complaint brought up in our usability study.
We now hook into the "show" event on .subscription_settings elements and
do some obnoxious math to move the scrollbar the way we want.
Closes trac #1015.
(imported from commit 5d9cee1ffc242eb7b743fdccd2bd76bf0a7ba060)
This can result in a significant performance benefit because we only
need to update the columns that changed..
(imported from commit 42bef1fcc58ad79bd864f89263fe82e90743ee5b)
The policy this implements is:
* 1 week for most persistent data (Clients, etc.)
* 1 day for messages
(imported from commit d57bb2c6b9626ffa2155c6d0ef9b60827d1f2381)
This saves 2 database queries per user in the huddle when sending the
first message to a particular huddle.
(imported from commit f71aa32df846fb4b82651a93ff9608087ffcaa5a)
This is in addition to only successfully reporting a given error once
per session. Previously, if an error was triggered many times before
the ajax call to report the error returned, we'd end up making many
ajax requests to report the error.
(imported from commit 559179e3c8c3fbf03bbb091a67361d447c80b7bb)
Also improve display of times passed -- we now use display short times
in milliseconds for easier reading.
(imported from commit 08e1e7e6acbef48453080864946f7602a3395e7c)
Previous we had around 4 copies of the logic for deciding whether we
should publish data via a SimpleQueueClient queue, a
TornadoQueueClient queue, or to directly handle the operation, which
resulted in their getting out of sync and buggy (see e.g. the previous
commit).
We need to add a lock around adding things to the queue to work around
a bug with pika's BlockingConnection.
I should note that the previous logic in some places had a bunch of
tests of the form "elif settings.TEST_SUITE" for doing the work that
would have been done by the queue processor directly; these should
have just been "else" clauses -- since we generally want that code to
run on development environments whether or not the test suite is
currently running.
(imported from commit 16bdbed4fff04b1bda6fde3b16bee7359917720b)
Keegan McAllister
Leo Franchi
Tim Abbott
Luke Faraone
Zev Benjamin