![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
(no subject)
Jan. 10th, 2006 08:22 pmSpent four hours today working at resolving a single line request: make %staff_person% the contact person for all on-sites.
This shouldn't have been too bad a request, and i thought i knew exactly how to do it- update the supplier table in the database with %staff_person%'s name and email for all products tagged as on-sites.
Then i remembered that the table in question also mirrored one in our old legacy database, and there is a DTS package which copies data from old one to the new one on a nightly basis. Not a problem- at this point it was a case of running the same update script against that database as well. Checking the on-site supplier listings in the directory verified this change was good. At this point, the total time investment was about fifteen minutes.
Unfortunately, some of these on-sites also have products listed- they run multiple tours or the like. This involved an entirely new set of digging about, during which i found a business rule- if there is no product contact listed, default to the supplier contact. This started looking promising, but none of the dozen different product tables was visibly called by the page where the entry was done, and i wasn't seeing any database calls which seemed to be passing the product ID number for which i was looking. Turned out that it was, but it was passing it in a weirdly named procedure which didn't leave a clue to what it was really doing called from ColdFusion code (so it really was an embedded SQL call, rather than a proc, now that i think about it). So, i went to that CF page, and changed one through the interface, profiling to see what got passed there. Turns out that although the rule provides a default case, there is no way in the interface to leave the field blank. Instead, it reads a value tied to each user, converts it into the user's name to present the name list drop-down on the entry page; and on the presentation side cross-references yet another table to return name, e-mail and telephone number. One single line request, six database transactions required to present just these two/three lines of information.
Does this shout performance nightmare to anyone other than me? Does the sheer incongruity of this database architecture baffle anyone? Even though this was pre-Agile, this is a prime example of what terrifies me about any methodology which prides itself on flying by the seat of its pants, extending things piecemeal as there is a need, and not documenting a damned thing.
Still, it feels nice to figure out that sort of puzzle. It's what i really like about my job, even if there are times i bitch about it making me crazy.
Came home, went into the bedroom, and discovered one of the two chinchilla cages was suprisingly chinchilla-free. The little buggers have been chewing on their cage for the last few nights, making a hellish racket, and apparently managed to chew through one of the things holding two of the panels together, and sometime during the day shifted it enough to escape.
So, we had a pair of loose chinchillas who are both new to the household and not particularly hand-friendly hiding in the bedroom. This required an entirely new adventure, and it wasn't clear for quite a while that they hadn't escaped and potentially become cat or dog food. Re-capturing them took probably forty-five pulse-pounding minutes.
I've bloody well had enough fun for one day.
This shouldn't have been too bad a request, and i thought i knew exactly how to do it- update the supplier table in the database with %staff_person%'s name and email for all products tagged as on-sites.
Then i remembered that the table in question also mirrored one in our old legacy database, and there is a DTS package which copies data from old one to the new one on a nightly basis. Not a problem- at this point it was a case of running the same update script against that database as well. Checking the on-site supplier listings in the directory verified this change was good. At this point, the total time investment was about fifteen minutes.
Unfortunately, some of these on-sites also have products listed- they run multiple tours or the like. This involved an entirely new set of digging about, during which i found a business rule- if there is no product contact listed, default to the supplier contact. This started looking promising, but none of the dozen different product tables was visibly called by the page where the entry was done, and i wasn't seeing any database calls which seemed to be passing the product ID number for which i was looking. Turned out that it was, but it was passing it in a weirdly named procedure which didn't leave a clue to what it was really doing called from ColdFusion code (so it really was an embedded SQL call, rather than a proc, now that i think about it). So, i went to that CF page, and changed one through the interface, profiling to see what got passed there. Turns out that although the rule provides a default case, there is no way in the interface to leave the field blank. Instead, it reads a value tied to each user, converts it into the user's name to present the name list drop-down on the entry page; and on the presentation side cross-references yet another table to return name, e-mail and telephone number. One single line request, six database transactions required to present just these two/three lines of information.
Does this shout performance nightmare to anyone other than me? Does the sheer incongruity of this database architecture baffle anyone? Even though this was pre-Agile, this is a prime example of what terrifies me about any methodology which prides itself on flying by the seat of its pants, extending things piecemeal as there is a need, and not documenting a damned thing.
Still, it feels nice to figure out that sort of puzzle. It's what i really like about my job, even if there are times i bitch about it making me crazy.
Came home, went into the bedroom, and discovered one of the two chinchilla cages was suprisingly chinchilla-free. The little buggers have been chewing on their cage for the last few nights, making a hellish racket, and apparently managed to chew through one of the things holding two of the panels together, and sometime during the day shifted it enough to escape.
So, we had a pair of loose chinchillas who are both new to the household and not particularly hand-friendly hiding in the bedroom. This required an entirely new adventure, and it wasn't clear for quite a while that they hadn't escaped and potentially become cat or dog food. Re-capturing them took probably forty-five pulse-pounding minutes.
I've bloody well had enough fun for one day.
