January 21st, 2002

  • sylphon

Saving journal

I wanted to start on a windows client for saving journal logs/histories, but couldn't find the bml in the cvs tree. Could someone mail it to me or point me to the right directory? sylphon@livejournal.com for emailing it. Thanks.

LJ Hackfest, numero dos

What: 2nd Ever Weekly LJ Hackfest
Where: My house! 7324 56th Ave NE
When: Monday Night, 7:00 - 9:00 pm
Bonus: At 9:00 pm, come to Dante's and drink with us! (Monday night tradition)

Who's planning on being there:

haven't heard from anyone else... RSVP if coming.

It's at my house because 1) free wireless, 2) big test DB server is here, 3) extra desktop computers for those without laptops, 4) nearby 7-11 for unlimited coke slurpees & munchies.

Work tonight is on:
  • clustering
  • UTF-8
  • rebuilding wendy with new harddrive
  • danis

Work day #2 - LJ on IIS?

okay... so i d/led the lj package via CVS as recommended by people in yesterday's post, then loaded up a site for it and all...
i added a bml extension to point to "C:/perl/bin/perl.exe -IC:\inetpub\journal\cgi-bin C:\inetpub\journal\cgi-bin\bmlp.pl".
i have configured a handful of files... the new documentation is more of a "here let me do it for you" rather than a walkthrough. i am quite stuck right now.
i keep getting this [Error: Undefined custom element 'PAGE'] error.
any ideas? here is the link :

thanks !

moose, transparent
  • avva

versioning the db

I have an idea that sounds nice.

Let's explicitly version the db schema. Create a new table, say "metadata", and store there the current vesion of the db schema, like "1.234" . The major version changes rarely when there're lots of integrated changes to the DB structure. The minor version changes all the time: every little alter, every new table, every field widening, etc.

Why? Because update-db-general.pl keeps getting more complicated, and its logic isn't executed in the same order changes were made, which hasn't been a problem so far but might be in the future. With versioning, update-db.pl would just look at the current version, then jump change by change to the most recent structure in the order changes were made. Every time we change something in the DB, we register a small routine keyed to the version number to do exactly this little change and nothing more. Changes of major versions may be coded to involve running larger external conversion scripts.

Maybe so far it's been a non-issue, or maybe not. I think it's the right thing to do, anyway. Thoughts?

P.S. Other things could be stored in the metadata table: for example running statistics of DB size or things like that. Can we graph, currently, how the DB has been growing during the last year?
  • halkeye

ban_email console command

Gots alot of patches tonight (some better then others)

First off.. console command to ban users...
Again, i'd suggest people focus on checking my english and word usage.
And my tables creation. I don't often create tables, so there are probably some tweaks that should be done that i do not know of.

This patch edits numerious files, so i just included it as one file..

As brad & co requested, this patch adds a console command to ban emails from support. So people can not spam up catagories..

I have tested all but the mailgate.pl bit, i have no idea how to interface with this... but the same code works in the submit.bml, so i figure it does..

Patch can be found here

Found one so far.. the statushistory thing.
With the userid of 0. they don't seem to show up in the statushistory page. Not quite sure at this point as how to deal with it, as i've just recently learned/remembered it was there.

Update: Forgot to mention that this can be tested using the test account here
  • halkeye

(no subject)

Next, patch to merge login_do.bml and login.bml

Modifies 2 files. login.bml and the dys scheme (For the actual login part)

patch can be found here

On a sidenote.. before i post some other merge patches
Are we going for xhtml spec?
or just the lowercaseing of tags?

This can be tested here