Wrapping Up the BTB
- Okay, Back to Business
- Match the Subcategory
- Selecting the Final Component
Ah, vacation. I took a few days off to get my head cleared and entertain some family from out of town. Four days. That ought to leave me refreshed and ready to tackle the big jobs when I head back in to work. So why do I feel like I need another vacation to recover from the vacation?
The rush started before I even left work. I had some new code going into that week's InformIT release. The release generally happens on Friday, and I was leaving Tuesday to be out the rest of the week until the following Tuesday. Our quality assurance and testing department is supposed to have the new code changes at their disposal no later than Monday. That left them two days to find my bugs (as if my code was going to have any!) and me two days to fix them. Fortunately, my code had no bugs of which to speak (big surprise).
I was free and clear, right? Sure, and I'm accepting the Nobel Prize for Physics next week. Product development decided to push off my changes for another week or two. There must have been a bad table tag, or a font size too big, or a GIF two pixels off. Sigh. I found out this delightful news at around 3:00 p.m. on Tuesday. If I wanted to leave at a reasonable hour to start "relaxing," I would have to work like a dog to back out my changes from the codebase.
On the surface, this would seem to be a simple task. We keep all of our code checked into source control. Each week's release has its own project. I could just check out last week's code and all would be well.
Things might possibly go that smoothly in the mythical state of Wishsconsin.
During the preceding two days, various changes had been requested by the "powers that be." A couple of other folks and I had checked in minor fixes and one rather important upgrade completely unrelated to the features that had to be backed out. Thus began the tedious process of deciding which ASP, Java, and SQL stored procedures had to be left in and moved up with the upcoming release. Leave in the wrong code and the unwanted features would appear. Take out the wrong stored procedure and the web site would crash with a rather unappealing error page.
Amazingly, a tidy little package of code changes got checked in by 6:00 p.m. They tested fine on one of our QA servers, so I could start relaxing—as soon as I finished fighting traffic on the way home.
To make an already dull story duller, the sprint went on for the next four days as I ferried out-of-town guests all over Indianapolis. When it was all done and their plane had departed, I had just enough time to collapse in a heap on my couch and realize...I had to get up for work the next morning. All in all, I have decided that vacations are better taken while I'm at work. The stress level is significantly lower.
Okay, Back to Business
Okay, complaining over, let's rush on. Scooby and the gang were just about to unmask the scary monster—in this case, the Browse Topic Box (BTB). When we left my last article, we were visiting a unique product_id. Using this product_id, we worked our way through the Java method StateDB.getNavigationidsFromProductid. That distressingly named function called the even more distressingly named stored procedure, sp_state_get_navigationids_from_productid. It was within this SQL stored procedure that we hoped to uncover just how a product was tied into the taxonomy and then into the state. The state would finally tell us how to pick the correct prebuilt HTML to display the BTB.
Without further ado—and there has been plenty of ado so far in this article—let's pull out our magnifying glasses and look at this stored procedure:
1 /****** Object: Stored Procedure 2 dbo.sp_state_get_navigationids_from_productid ******/ 3 CREATE PROCEDURE [dbo].[sp_state_get_navigationids_from_productid] 4 5 ( 6 @prodid uniqueidentifier, 7 @navid uniqueidentifier OUTPUT, 8 @tabid uniqueidentifier OUTPUT 9 )
Breaking here, we see the stored procedure being created with a variable called @prodid specified (implicitly) as input. This is, of course, the product_id. The calling method expects two values, the navigation ID and the tab navigation ID. It gets these in the variables @navid and @tabid, respectively.
10 11 AS 12 13 DECLARE @nid uniqueidentifier 14 DECLARE @nid2 uniqueidentifier 15 DECLARE @tid uniqueidentifier
Here we set up some variables used internally by the procedure.
16 /* Pull the navID of the highest ranked, matching category */ 17 SELECT TOP 1 18 @nid = n.navigation_id 19 FROM 20 products p, 21 product_tax_mapping ptm, 22 reference_dimension rd, 23 navigation n 24 WHERE 25 p.product_id=@prodid 26 and ptm.product_id = p.product_id 27 and ptm.reference_id = rd.reference_id 28 and n.facet_column='category' 29 and rd.category = n.facet_column_value 30 ORDER BY 31 n.sibling_priority ASC
We have reached the first section that does some heavy lifting. If you recall, to determine the state of a page uniquely, a navigation ID and tab navigation ID are required. This section of code attempts to determine a top-level navigation ID using a join on four tables. The navigation table uses the navigation_id as primary key. Also in the navigation table, and of interest to us, are the columns facet_column, facet_column_value, and sibling_priority.
The reference_dimension table contains our unique taxonomy tree. I mentioned in the previous article that the reference dimension was five levels deep. For the purposes of the BTB and state, all we care about are the top two levels, category and subcategory. The reference_id is a uniqueidentifier that serves as the primary key for the reference_dimension table.
The products table contains a listing of each and every article, book, and sample chapter on the InformIT site, each keyed with a unique product_id. The product_tax_mapping table ties a product_id to one or more reference_ids, and thus into the taxonomy. The canny among you probably see where this is leading.
Line 25 above uniquely selects the proper product record out of the products table by matching the product_id that we passed into the stored procedure. In line 26, we tie in the product_tax_mapping table. The tax in product_tax_mapping comes from taxonomy, natch. InformIT's intrepid editorial staff has tagged this product with a value or values from the taxonomy, each of which is identified by its own reference_id. Lines 26 and 27 select all of the relevant reference_ids that relate to our product.
On line 28, the aforementioned navigation table field, facet_column, is invoked. Line 28 matches only those records that correspond to the top-level reference_dimension value, category. Line 29 pulls everything together by requiring that the navigation table facet_column_value match the corresponding reference_dimension category field. In other words, I want the category programming. There is a navigation level that corresponds to programming. The product might also be tagged with a reference_dimension category called development. There is no top-level navigation entry for simply development (check the BTB and see for yourself), so we wouldn't want to bother with that record.
Lines 17, 30, and 31 ensure that we receive only the top-ranked match. The sibling_priority field in the navigation table allows our editorial staff (still as intrepid as ever) to rank which category they feel is most important relative to the others in displaying a product's navigation.
If all went well, the variable @nid should now be set to a uniqueidentifier that matches our product to the most highly ranked reference_dimension category that has a BTB entry.