Previously, setting data props on a thing would result in a SELECT to
determine which data properties already existed, and then a sequence of
INSERTs and UPDATEs (with some batching) to get the database in the
right state.
The account master wasn't too happy with those extra selects, so we
made it so that the app would optimistically UPDATE and if no rows were
changed do INSERTs instead (with appropriate batching as above).
Unfortunately, this greatly increases the number of operations done when
adding new data props, such as at thing creation time, and on some
tables that's almost entirely all of the workload.
This patch takes advantage of the fact that we know no data attributes
will exist at thing creation time and therefore we can blindly INSERT
without doing UPDATEs or SELECTs first to try and reduce the number of
extraneous operations we do.
Updates an occurrence of "index" that should have been changed to campaign._id
during the campaign thing reads change. This fixes two bugs:
(1) Campaigns were being incorrectly marked with "update failed" when edited
by an admin or sponsor even though the update was successful.
(2) Campaigns were not being automatically marked as freebies when edited by
an admin or sponsor. (These have to be set as freebies in self-serve because
they are billed separately.)
This change also checks for an empty user string so the update function can
be run in paster shell.
This is intended to replace Relation. Relation works by putting each individual
relationship in its own Row. This means that doing a fast_query (cross-product)
results in a large multiget that likely touches every node on the C* ring.
DenormalizedRelation instead puts all of the relationships into a single row
per thing1 and only fetches the desired columns on read. This means that most
of the time, we'll do a single-row lookup to determine what we want and the
majority of the time we will get a very fast response from the row-level bloom
filters indicating that no such relationship exists.
The row cache should be disabled for this column family as the rows will be
VERY wide.
Cassandra View class for storing account activity(the columns) by
subreddit (the keys).
Columns have a TTL of 15 minutes to expire out inactive accounts.
Note that pylons.wsgiapp uses pylons.i18n's get_lang()
and friends, instead of our modified versions in
r2.lib.translation. This means that setting 'lang' in the
conf causes it to try and 'help' us by looking up PO files
in r2/i18n. Changing the ini files to use 'site_lang' as the
key gets around that.
Updates javascript to use min bid defined in the app config instead of using a
hard-coded value, and allows admin to override min bid.
Updates validation code to allow admin to override min bid on the back end.
Previously, only old-style SHA-1 passwords were upgraded on login. Now,
if we change the bcrypt work factor, bcrypted passwords will also get
the upgrade treatment.
The base LiveList set up is similar to LiveConfig; it sets a watch and
will get notified by ZooKeeper when the data changes. Sometimes we don't
need data very frequently, if at all, and would rather eschew the watch
for a pull based model (asking ZK for the data only when needed.) This
is particularly helpful if we're doing write-only changes to a
datastructure read only in one place (such as a queue processor).
