location_id = 1
location_ns = 1
repeat_of = 1
+object_type = 2
+scope = 1
[notice__keys]
id = N
[reply]
notice_id = 129
profile_id = 129
-modified = 384
+modified = 142
+;modified = 384 ; skipping the mysql_timestamp mode so we can override its setting
replied_id = 1
[reply__keys]
notice_id = K
profile_id = K
+[schema_version]
+table_name = 130
+checksum = 130
+modified = 384
+
+[schema_version__keys]
+table_name = K
+
[session]
id = 130
session_data = 34
created = 142
-modified = 142
-; Warning: using DB_DATAOBJECT_MYSQLTIMESTAMP (256) causes DB_DataObject
-; to SILENTLY REMOVE ATTEMPTS TO SET THIS FIELD DIRECTLY, which is pretty
-; bad because the default behavior for auto-updated TIMESTAMP fields is
-; to use local time. Local time can't be compared to UTC in any useful
-; way, so doing that breaks session GC.
-;
-; Instead we'll use the plain datetime settings so it'll actually save the
-; UTC value we provide when updating.
-;
-; Long-term fix: punch MySQL in the face until it understands that local
-; time is a tool of the cyber-devil.
-;
-;modified = 384
+modified = 384
[session__keys]
id = K
language = 2
timezone = 2
emailpost = 17
-jabber = 2
-jabbernotify = 17
-jabberreplies = 17
-jabbermicroid = 17
-updatefrompresence = 17
sms = 2
carrier = 1
smsnotify = 17
nickname = U
email = U
incomingemail = U
-jabber = U
sms = U
uri = U
[user_location_prefs__keys]
user_id = K
+
+[user_im_prefs]
+user_id = 129
+screenname = 130
+transport = 130
+notify = 17
+replies = 17
+microid = 17
+updatefrompresence = 17
+created = 142
+modified = 384
+
+[user_im_prefs__keys]
+user_id = K
+transport = K
+; There's another unique index on (transport, screenname)
+; but we have no way to represent a compound index other than
+; the primary key in here. To ensure proper cache purging,
+; we need to tweak the class.
+
+[user_urlshortener_prefs]
+user_id = 129
+urlshorteningservice = 2
+maxurllength = 129
+maxnoticelength = 129
+created = 142
+modified = 384
+
+[user_urlshortener_prefs__keys]
+user_id = K