|
|
|
narrowing conditions
Friday, May 21 2010
One of the features of my generic database-editing tool's relation-following code is that it allows the tool, when providing an editor for a record in a table, to display dropdown lists of the options available in other tables that relate back to the one being edited. In other words, if you have a database for a bike store and are editing information about a model that is for sale, the "manufacturer_id" field, instead of just being a form item allowing you to type in the identifying number of a manufacturer in the manufacturer table, can instead be a dropdown list of all the manufacturers in human-readable form. This limits the possibility for error and makes it possible to change a manufacturer easily without having to look anything up. The problem, though, has been that some of these dropdown lists can be enormous. I partially-solved this problem by making it so that if the dropdown should contain more than 100 items, then you get a popup-based picker instead of a dropdown, and this provides the same human-readable functionality but adds a flexible search system and supports an unlimited number of items.
But even that solution doesn't address another problem that occasionally crops up. Sometimes only a small subset of the records in a related table have relevance to a record being edited. For example, if you have an appointment in a scheduling database, and there is a dropdown for "client," one for "office," and another for "practitioner," then it doesn't make sense to include practitioners or clients belonging to other offices if an office has been selected (though if one hasn't, then they should all be shown).
Today I spent a lot of time implementing a system allowing for the automatic narrowing of possibilities available across relations. I added a new field called "narrowing_conditions" to the "relation" table (which stores the information and meta-information about relations), and it allows me to enter either a WHERE statement, a JOIN statement, or a combination. The SQL snippet in narrowing_conditions allows for tokens of the form $colomn_name, allowing the narrowing_conditions to refer to data in other fields outside the field being narrowed. Examples of a working narrowing condition include "where office_id=$office_id" and "join client_office_map m on m.client_id=a.client_id WHERE m.office_id=$office_id."
Here is something I wondered today: why isn't Barrack Hussein Obama on a fucking military destroyer headed to that leaking BP oil platform? Screw whatever commencement address you are secretly planning and stand there on a ship deck and tap your fucking toe until the shit is fixed!
And here is something else I wondered today: why doesn't Rand Paul explain how a libertarian purist would have saved the global finance system in the Fall of 2008? But then it occurred to me that he believes lunch counters could have been desegregated by market forces alone.
In other scrambled bits of eratica, there's this piece of three-year-old investigative journalism I stumbled upon the other day about a company called LifeLock that purports to protect its members against identity theft. But evident suggests that Robert J. Maynard, Jr., one of its founders, had used his father's identity to borrow nearly $200,000 without his father's permission. And Maynard continues to use his arrest for check kiting as a cautionary marketing tale about the horrors of identity theft, though the reality (as uncovered by this unusually thorough piece of journalism) is that he evidently kited the checks he was arrested for kiting and that no one had used his identity to impersonate him.
For linking purposes this article's URL is:
http://asecular.com/blog.php?100521 feedback
previous | next |
