Store – Chaining Multiple Records

Resolution 99975 corrects two methods to restore the correct “chaining” of multiple records in the TW_Blob table.modifies.  They are:

1. Store.Glorp.StoreDescriptorSystem>>tableForTW_BINARYBLOB: aTable
2. Store.Glorp.StoreDescriptorSystem>>tableForTW_BLOB: aTable

Blob Chaining

When a package is published, many of the associated Smalltalk objects are encoded as byte arrays and stored in one or more rows of the TW_Blob and/or TW_BinaryBlob tables.  The objects stored as “blobs” include:

      comments

                  class

                  namespace

                  package

      definitions

                  defineClass: 

                  defineNamespace:

                  defineSharedVariable definition that are executable "workspace snippets"

      package

                  property values

                  associated files

One row is used when the size of the byte array is 32,000 bytes or less. Otherwise, multiple rows are used. Except for possibly the last one, each holds 32,000 bytes.

The blobType field of the table does double duty as either a type indicator for single-row-only blobs and for the last row of multiple-row blobs. 

Valid blobTypes are:

1. any other object
2. instance of ByteString
3. instance of TwoByteString
4. instance of ByteArray

A negative value in the blobType field is the negated primary key of the row it “points” to.  For example, a large TwoByteString with TW_Blob table primary key 296 might be stored as:

The bug in Cincom® VisualWorks® 7.8 that is corrected by this resolution could cause a negative blobType field value to be left as nil when publishing to a Microsoft SQL Server-backed repository.  If that happens, the write to the database would try to INSERT a row into the TW_Blob table that had an SQL NULL value for the blobType field.  If the repository was created with VisualWorks 7.8, then the blobType field has a NOT NULL constraint, and a constraint error occurs preventing the write.  However, if the repository was created with a VisualWorks version before 7.8, the NOT NULL constraint on TW_Blob.blobType is not present and the INSERT succeeds without a warning or error message.  When reading from the database, the entire chain will not be followed and therefore the (partially) reassembled byte array will be truncated.

Querying the Repository Database for NULL blobTypes:

Use the “Store” menu “Store Workbook…” menu item.  In the resulting workspace, the expressions that can be used to determine whether the blob tables have had any such rows with NULL blobType field are inserted.

session accessor executeSQLString: 'SELECT *
FROM NEWBERN1.BERN.TW_Blob WHERE blobType IS NULL'.

and

session accessor executeSQLString: 'SELECT *
FROM NEWBERN1.BERN.TW_BinaryBlob WHERE blobType IS NULL'.

We hope you find this useful. 

“Smalltalk is fun!”