Re: SE + blobs

>Date: Thu, 16 Jan 92 19:43:28 -0800 >From: uunet!nas.nasa.gov!bross (Wilson S. Ross) >Message-Id: <9201170343.AA16757@splatter.nas.nasa.gov> >To: johnl@obelix.informix.com >Subject: SE + blobs > >>Aside a little now, if OnLine supports BLOBs and SE doesn't then what's to >>stop users of SE just adding a column into a table giving a filename pointer >>to the disc storage of a BLOB and accessing it that way? It would only take >>around twenty to thirty good C routines to drive it. > > Twenty to thirty? Read, Write, Open, Close, ... A Dozen at the outside. > But more to the point, you cannot access an OnLine BLOB.. > >I think he means, simulate blobs w/ files, using filenames stored >in the SE dbase as pointers for custom routines to do blob things. >Whether it would work would depend on what sort of interface he wanted >& how much effort for it. > >Bill Ross >NASA Ames Yes; I realised that might be what was meant. I've considered it on several occasions, and for most purposes, all that is required is the name of the "blob" file in a table in the database, and access to fopen, fclose, fread, fwrite et al. This can be done trivially in C (ESQL/C); it's marginally harder in I4GL, but then I4GL generally doesn't handle blobs in memory very usefully, and blobs in files are dead easy to simulate. A more serious issue is the transaction management and recovery side -- blobs in OnLine are recoverable, but care would be needed for "blobs in SE" using filenames to be recoverable. To handle that, it might be best to have a blob-description table, which had a a two-part primary key. The first part would be an integer generated from a "ticket-counter" table. (A ticket-counter table consists of a single column, a serial, and is normally empty. When a new ticket number is required, the user inserts a row into the table and retrieves the new serial number, and promptly deletes all the rows in the table.) The second part of the key would be a version number; this could be a smallint, and integer, a date or a datetime, according to whim. The main tables "storing" blobs would actually simply store the ticket number; the "blob" manipulating software would automatically retrieve the most recent version of the "blob", update it and so on. The "blob" filenames would be controlled by the blob software, not the user (though it would be as well to make their location configurable). I guess you would need the following routines: blob_insert blob_delete blob_update blob_select (with flag to lock?) blob_commit blob_rollbk Exactly what arguments they take, and the detailed semantics of commit/rollbk and their interaction with insert/delete/update would need a little care, but those 6 routines (not 20-30) should see you through most circumstances. Yours thinking as I type, Jonathan Leffler (johnl@obelix.informix.com)