Some things about DBI I did not know before

Hmm, I've been thinking about this a bit, and I'd like to start noting down what I'm working on, informally.

What this means is that I'll be posting more: sometimes I'll be posting more technical stuff, other times I'll be posting less technical stuff. More technical entries like this one, which include code, will be tagged with "development", so you can either filter that out or read only that. We'll see how it turns out.

Today, while reviewing a patch to allow support requests to be mass-closed, I stumbled upon code that was completely unfamiliar to me:

$dbh->selectall_arrayref( "...", { Slice => {} } )

Usually the first argument to one of the database calls is undef; I've never bothered to figure out why, just chalked it up to something that was over my head. Tonight, it was obviously time to figure out what that first parameter was for!

Discovery number one: the first parameter is not magic. It's actually a hashref of additional attributes, in case you need to override the default settings (such as whether to commit, what to do when the database errors, what format to return the results in). Usually we just pass in undef because we don't need to override the defaults.

Discovery number two: perldoc DBI is useful for seeing the entire API of DBI, but it's very technical (I skipped sections that I thought were irrelevant; it turns out that one of those irrelevant portions was actually relevant)

Discovery number three: unrelated to previous, but taken from perldoc DBI, you can look up the last SQL statement that your program used, using warn $dbh->{Statement} or warn $sth->{Statement}. That prints out the last SQL statement into your logs, including the values of any variables -- useful when you're deep into debugging something.

Discovery number four: perlmonks.org has a page for DBI recipes, which was what made me realize that the whole thing with Slice? Was so you could return a list of hashrefs.

Bug 2580: Smarter Tag Tracking

Chose an easy bug to do while in the middle of doing reviews, this one was from suggestions -- Bug 2580: Smarter Tag Tracking.

Let's say you were reading an entry and decided that you wanted to be alerted of all new entries that are on the same topic, by tracking all new entries posted under the same tag as one on this entry.

You'd click on the "Track" link, then through to "More options", and then have to scroll through the journal's entire list of tags in order to find the tag you're looking for. Something like this:

( image of the complete list of all tags on the journal )

So what was suggested was that we give priority to the entry tags, so they can be easily selected, while still listing the rest of the tags. So something like this:

( image of the tags on this journal broken down into two groups: entry tags and other tags )

This one was pretty straightforward -- the toughest part was figuring out how to make the tags dropdown aware that we wanted to target a specific entry. The next toughest part was figuring out how to make the LJ::html_select function handle optgroups.

And done; another suggestion implemented *G*