LiveWhale, our CMS, is essentially a module-based system. Individual modules can be provided to our customers on a per-client basis. Each module is a self-contained element, that “registers” itself in the CMS framework, thereby establishing its functionality throughout. A module is responsible for creating and managing its own data, but if it is flagged as group owned, access to that data is handled by LiveWhale’s users and groups system.

It is, of course, possible for an administrator to manage those users and groups, and should a circumstance arise in which a group should be targeted for deletion, LiveWhale automatically cleans up data associated with that group (whether it is stored in a database or the file system) so that it is not orphaned. (This is in fact the case with any piece of data which “contains” additional hierarchical data.)

The mechanism we have in place for this is simple, but it is also flexible. Each piece of associated data that has to be cleaned up by a parent marked for deletion can optionally be given to a handler deletion function. For example, if a piece of news stores an image in the file system, the handler function is activated to clean that up as well.

Eventually we added a global activity log to our CMS, LiveWhale. Activity is associated with a user and a group, making this data group owned. As it turned out, the group deletion mechanism possessed a flaw. LiveWhale’s internal delete routine initially expected the logic about what a handler function had to do, if anything, to come from the handler function itself. In fact what it needed to do was to first deduce if a handler was optimal for a particular type of data at all. The activity data made this clear, when there was suddenly a need to delete hundreds or thousands of individual pieces of data which were designed to be stored in huge quantity over a long period of time (unlike with news management, for example). Pushing the handler logic up into LiveWhale’s delete routine made it no longer necessary to perform logic a hundred or thousand times when the result was always going to be the same, and a one-off deletion procedure could alternatively be used for the bulk data.

This drives home the point that building something requires either the proper foresight to know how that system has to conform to conditions that haven’t yet come about, or ensuring that the foundation you’ve already built adjusts to appropriately handle new features as you add them. Fortunately, our LiveWhale development process utilizes a variety of monitoring tools and diagnostic tests which inspect the system closely to continually perform a sanity check on the results of code execution over the product’s development lifetime. This was a case where the system noticed the deletion flaw even before I did.