January 11th, 2002

  • mart


Patch created.

When $LJ::READONLY is set on in ljconfig.pl, the most commonly-accessed features which require database writes are disabled in some form. In most cases, this comes in the form of removing the auth fields and replacing them with a message saying the site is down. There are some special cases...

  • talkread.bml loses some buttons from its @linkele (the blue bar thing) which link to things which require database writes.
  • The reply links on talkread.bml vanish, the first of which being replaced by a message explaining why.
  • The delete links on comments vanish.
  • talkpost.bml refuses to output anything bar an error message.
  • The protocol handler returns a warning to clients at login, and error messages when commands are executed which do database writes.
  • A little blurb goes on the front page.
  • The support section loses the links to post a question and read questions (since you can't answer them right now anyway)

In addition to these, I also recommend the following changes to ljcom, which I don't do...

  • Disable all of the stuff about paid accounts. It won't be nice if people try to buy paid accounts when the site's read-only and LiveJournal ignores the acknowledgement from paypal.
  • Edit the dystopia BML scheme to display a small warning somewhere and also remove links to the main things which will require database edits.

The modification to LJ::auth_fields is a hackish catch-all I just threw in to cover anything else in some way, relying on the fact that we never use auth fields for anything which doesn't edit stuff. At some point when readonly checking is added everywhere, that stuff should be removed because it doesn't really belong there.

I also fixed up some HTML to be well-formed XML but not everywhere.

i wanna be a cowboy
  • teedz

Is this a known bug?

[Note: I'm using mozilla on linux, I haven't yet tested it in Netscape]

1. Create a new journal, while logged in as your current account.
2. Verify this journal via the email URL
3. Go to the user menu and Click "Your Settings | Personal Info"
4. At the confirmation screen, rather than hitting "Proceed", select "click here"
5. Login as new account.
6. In the Edit Personal Info page; Note that all information displayed is for new account; Go down to "Your Picture".
7. Click "Go here" to add/create a new one.
8. On the Upload Picture page, submit an image From File; Click "Proceed".

Expected Result: 'Upload Picture' page gives the name of the new account (the one you are editing) in the 'Username' dropbox; Image can be uploaded for new account.

Current Result: Your original (main) username[s] appear in the 'Username' dropbox. Furthermore, uploading an image using the preselected (main) username is not challenged -- image is uploaded to original account, rather than new LJ account.

I dunno if this is a downright bug, or "the way things work", but it's certainly misleading.

Conversion: Take 3


Plan 1: I knew conversion of the data would take awhile, but didn't know how long. I wrote the conversion code and ran it on my test machine. A few seconds and it was done. Ran it on a copy of the real database.... whoa, this is going to take weeks.

Plan 2: Did a billion things to make the conversion quicker. Kept working on this for about a week, each day making it faster. Timed it on a fraction of the real database. A full conversion without even the logtext/talktext tables would take several days. I figured we'd do the *text tables on demand, as previously mentioned. Even with the read-only operation of livejournal running while the database was converting, people would get angry after 76 hours of read-only downtime.

Third time's a charm: We convert nothing immediately. I'll have to alter user (a few minutes), memorable (a few seconds), and topic_map (a few milliseconds). A new column in user says what cluster they're on (this was already planned). But instead of cluster "0" meaning "the first cluster", it'll now mean "no cluster... the old tables". The tables that clustered data store into will be called log2, logtext2, talk2, talktext2, talkprop2, etc. Those can coexist in the same database as the old tables.

In ljconfig.pl where we define clusters, cluster 1 will be on the same host for now, and we'll convert a user at a time. Here's how that'll happen: a new capability class named "in conversion" is allocated (bit 6 is free?), with a class capability of "readonly = 1". All the code should check if that user's readonly cap is set. If so, don't allow writes, because some other process is the middle of moving the user's stuff all around. At the end of that user's move, the clusterid is changed, and then the capability class bit is turned off, and then all the old stuff is deleted from the previous cluster (or cluster 0, as in the case of a conversion from non-cluster).

  • No global downtime. Each user will have a bit of downtime (proportional to their amount of data), but everything else still works during that time.
  • No code fork. We won't need the pre-cluster code and post-cluster code. (I don't need to learn more CVS crap! hooray!)
  • No double copying. Before we would've needed to 1) convert everything, and then 2) copy everything to their destination cluster. Now we can do the conversion and copying to destination cluster at the same time.
Questions / Objections / Brilliant foresight / Fellatio offers?

CVS Back

CVS server is back and better than ever.

Happy anonymous checkin'-outin' !!

(the reason it went down is because I rebuilt Marklar the other day.)