Database Administration

Deleting Unneeded References

The garbage collection and compaction tools can be used to eliminate structures from your Vision database network that are no longer active. There are some structures associated with property values and methods that are not automatically purged by these tools. Several messages have been defined that allow you to flag additional information for the garbage collector to free.

Vision properties and collections manage internal structures for each type (i.e., class) of value stored for any of its instances. Vision properties and lists retain references to types even after none of the instances they represent refer to values of the type. To support the selective deletion of unneeded references, two primitives are available: the cleanStore message operates on the instances of a class and the cleanDictionary message operates on the message dictionary of a class. Both messages are defined at the class Object and return a Boolean value indicating whether the recipient object was "cleaned". The cover methods rcleanStore and rcleanDictionary can be used to recursively clean the stores or dictionaries of the recipient object. The messages cleanStoreAndDictionary and rcleanStoreAndDictionary can be used to perform both types of clean up for the recipient object.

The cleanStore message can be sent to a class to eliminate any unneeded references for its properties. For properties that reference instances of other user-defined classes, an alignment operation is also performed if necessary. The alignment operation replaces a chain of pointers with a single pointer in cases where the referenced class has had additions or deletions since the last time the property was updated, thereby speeding up access. The cleanStore message should also be explicitly sent to any properties that reference collections to align these structures as well. For example, if Security defines a fixed property heldList that contains a list of Holding instances, you would use:

  mySecurity heldList cleanStore

to align the list as well as to purge old, non-referenced structures. If values of heldList are clustered for all securities, you only need to run cleanStore for one element. If the values of heldList are not clustered, you could use:

  Security instanceList do: [ heldList cleanStore ] ;

The message cleanDictionary is the class level analog of cleanStore. It aligns the class dictionary and purges unneeded define:toBe: and defineMethod: definitions.

It is useful to periodically clean the stores and dictionaries for each class in your database. For most classes, this simply involves executing the cleanStoreAndDictionary message. Classes that contain property values which reference lists of elements need to also execute the cleanStore message on any of these properties as well. Also, any class that manages multiple clusters (i.e., parallel stores created using the newPrototype message) must explicitly send the cleanStore message to each of these clusters.

The message cleanupClassStructures has been defined at the class Object to perform the basic cleanStoreAndDictionary operation on the recipient and display a confirmation if the recipient required cleaning. This message can be redefined for any class that requires additional steps. For example, to redefine this message to also clean the heldList property at Security, use:

  Security
  defineMethod:
  [ | cleanupClassStructures |
    ^super cleanupClassStructures ;      #-- runs the general version
    heldList cleanStore
        ifTrue: [ "-- cleaned Security heldList" printNL ] ;
    ^self
  ] ;

---

Deletions

Object Deletion

Instances can be flagged for deletion without actually removing the object from the database. This is the recommended approach for most applications, giving you an opportunity to undelete an accidental deletion if necessary. Several properties have been defined at Object to aid in tracking deletion information. Undeleted objects have values of NA for all of these properties:

  Property         Definition

---

  deletionFlag     TRUE if flagged for deletion
  deletionDate     Date object was flagged for deletion
  deletionReason   String explaining deletion reason

The expression:

  object flagForDeletionWithReason: string

     where object    is the object to be flagged for deletion
	string          is the reason for deletion

is used to flag an object for deletion. It is defined to perform the following operations:

1. Set the value of deletionFlag to TRUE.

2. Set the value of deletionDate to the current date.

3. Set the value of deletionReason to the supplied string.

4. Run the object's implementation of the method cleanupDeletedObject.

The cleanupDeletedObject message executes the following steps:

1. Run the object's version of cleanupLocalAttributes. By default, this message does not do anything. It should be redefined as appropriate for specific classes.

2. Run the object's version of cleanupLocalNames. By default, this message deletes the object's code from the class' naming dictionary, if one exists. This message can be redefined or augmented at specific classes as needed.

Several messages have been defined to utilize the deletionFlag property:

  Message      Definition

---

  isActive     TRUE if object's deletionFlag isNA
  isntActive   TRUE if object isActive != TRUE
  isDeleted    Same as isntActive
  isntDeleted  Same as isActive

The message activeList is used to return all instances of a class (as base objects) that are active and not default.

To actually delete an object from the database, you need to send the delete or rdelete (recursive delete) message to it. The recursive version should normally be used, since it deletes the instance of the object at all levels of its inheritance path.

Note that objects should be deleted with care. If you delete any object that is referenced by another object (e.g., as the value of a property), the reference will be replaced by a reference to the Null or Shadow instance for the deleted object's class. As a result, the old reference will continue to respond to the same messages; however, all properties of the Shadow instance will contain NA values. You cannot assign values into the properties of the Shadow instance. To determine if an object is the Shadow instance, you can send it the isInternalDefault message.

Message Deletion

Messages should be deleted using the deleteMessage: message. The general form for message deletion is:

  object deleteMessage: "message"

Other Deletions

The delete: message can be used to remove a point from a time series, an indexed list, or a dictionary object. For example:

  Named Security delete: "IBM"

deletes the name IBM from the Security class' naming dictionary. The general forms of this message are:

  dictionary delete: string

	where	dictionary is an instance of the Dictionary class
	and	string is an instance of the String class

  ts delete: date

	where	ts is an instance of the TimeSeries class
	and	date is an instance of the Date class

  ilist delete: object

	where	ilist is an instance of the IndexedList class
	and	object is an object that was used as an index in this list

---

Schema Message Management

The class Schema MessageImplementationDescriptor maintains information about the messages in your Vision database. Each message defined for any class in the schema database has a corresponding instance in this class. These instances store information about the message itself including its type, function, and description, as well as tracking changes to methods over time.

All classes created using a variation of the createSubclass message will automatically be available in the database. New instances of the Schema MessageImplementationDescriptor class are NOT created automatically. Each time you use one of the define messages, the class is flagged to indicate that new messages are pending. To process and refresh all messages, execute the expression:

  Schema processAllMessages

This process creates and refreshes message descriptors in the schema database as needed. It will generate a report similar to the one illustrated below:

  Schema Message Cross Reference Last Updated: Fri Oct 30 11:59:17 EST 1992
  ---  Current Counts  ---
  CD:             172
  MD:            1968
  MID:           4133

  ---  Classes To Update  ---
  BuiltInWorkspace
  CoreWorkspace
  Environment DBA Schema
  Environment DBA DDMS

  ...  Creating New Messages
  ...  Refreshing Messages
  ...  Cleanup

  Schema Message Cross Reference Last Updated: Tue Nov 10 15:57:02 EST 1992
  ---  Current Counts  ---
  CD:             172
  MD:            1970
  MID:           4151

  18 Created.
  25 Refreshed.

This report displays the status of the schema database prior to processing, the list of classes processed, the status after processing, and the number of messages created and refreshed. Depending on the number of classes to process, the update time will range from a few seconds to a few minutes. Most installations incorporate this procedure into a standard nightly update.

Related Topics

• Running Vision