delete terms where UWDAID=(select UWDAID from terms where Name="xxx")
But the "Delete Concept" button should do more than that. It should make a rudimentary attempt to maintain database consistency, by checking to see if it there are any references to it in the links table, and if so, warn the user before removing them. It should also keep the display in sync.
So a possible algorithm would be:
- find out how many links refer to the term (using a stored procedure?)
- confirm this number with the user, allowing them to cancel the operation
- delete all the links we found (perhaps using marks? probably not)
- delete the concept from the terms table
- clear the Concept, Term, and Attribute inspectors
- search for the concept in the hierarchy display, and if found, remove
it and any of its expanded subtrees
Here's how I'm going about the implementation: - make a new method in the "cinspector.[hm]" files, call it "deleteConcept" - open the interface in Interface Builder - add a "Delete Concept" button to the Concept Inspector window - control-drag from the new button to the cinspector object, and connect it to the deleteConcept method - save & quit from IB - (in the new method, write the code to implement the above algorithm as follows) - experiment in ISQL to arrive at the SQL that will do a deletion - embed the generalized SQL command directly in the C code, compile & run, make sure it works - add a confirmation dialog to pretty it up - add more code at the beginning of the new method to check for the existence of links that refer to the concept the user wants to delete - think about how to remove said links from the hierarchy window automatically - REALIZE THAT BLIND DELETIONS OF LINKS WILL ORPHAN WHOLE SUBTREESIn order to guarantee the removal of all the links in question and all the subtrees below them, it would be necessary to do a recursive tree walk in each of the separate hierarchies, deleting whole groups of links along the way. This seems to me to be excessive and potentially catastrophic.
Therefore, I decided to require the user to remove links manually before using the "Delete Concept" button to remove the terms themselves. It would be possible, as CR pointed out, to check for a special case of the concept only occurring as a child in any hierarchy, then do a relatively simple SQL command and make sure that the hierarchy window was updated accordingly; but I don't like to do a lot of work for a special case and leave the general case unsolved.