Background
First, a bit of background. Movable Type has been designed to work with multiple types of databases. Two common examples are mysql and postgres. If you are using the Enterprise version of Movable Type, you can add Oracle and MS SQL Server to that list. Each of these databases has a different (but somtimes similar) set of commands it understands, and a different set of features.
Whenever Movable Type needs to store or retrieve a bit of information about one if its objects (entries, users, templates, comments...) it will need to talk to the database. This 'talking' is all centralized in one part of the Movable Type codebase, which knows what to do to store and retrieve information. It is at this place that Movable Type's requests to store or get a bit of information get 'translated' into the proper set of commands to be sent to the particular type of database that is being used.
Limited use of database features
In order not to complicate this process too much, Movable Type tries to keep itself to using a limited set of commands and features, shared by all supported databases. This often means not using certain advanced features a certain database offers, and sometimes replicating this functionality in Movable Type by using a workaround.
An example: many databases offer a feature called "cascading deletes", where deleting items from one table automatically causes related items from another table to be deleted as well. This would be very handy, for example, to automatically delete comments when their parent entry gets removed.
Movable Type's workaround
Unfortunately, not all databases have this feature. For this reason, Movable Type cannot use it. Instead, Movable Type's objects have been programmed in such a way that they "know" that when they are being deleted certain other objects need to be deleted or changed as well (for example, to update entry counts...).
Now to get back to the original point: if items from the database are directly edited or deleted by someone, none of these actions take place. This means items may get orphaned (comments without entry), counts may get out of whack or worse, the database might get corrupted.
I think you'll agree that none of the above are things you would like to see happening in your database.
How to change data in the database without getting into trouble
But what if you absolutely, positively have to change some data in the database? Here are some things to try, before breaking out the direct database commands:
- See if you can't access whatever you need to access via Movable Type's normal user interface
- Use Movable Type's Perl API to write a little script to change the data. This is simpler than it sounds. (If there is enough demand for it, I'll write a short article about it). When you are using Movable Type's own objects in your code, all "automatic" actions upon saving or removing get executed properly, saving your database from disaster.
- Consult someone with thorough knowledge of e inner workings of Movable Type: perhaps whatever data you want to change does not have any automated actions associated with it, so it may be safe to do it after all...
Use Movable Type's Perl API to write a little script to change the data.
worms in dogs