danny@itm.UUCP (Danny) (10/16/85)
Ok, as long as we're talking Unify, I might as well share some
of my experiences. Overall, Unify is an adequate product, with few
bugs, and one glaringly obvious assumption.
As for speed, it seems a bit on the slow side, particularly for
updates done via a C program and the supplied interfaces.
I have written a specialized database application, whose update is:
get a record (read a chunk of disk into a struct)
play with the fields
write it back out
A Unify update works like:
get a record (many different ways to do this)
get a field (do this many times to get all the fields)
change a field (many times too)
put a field (update)
Pfield, is a BIG mother. Does one of everything. Performs sanity checks,
does locking, writes new field onto the disk. On the one hand, once
you've done the pfield, the data is out there, period (aside from delayed
writes inside the kernal). But the other side is:
Consider the following pseudo-code:
for (each record to be updated)
for (each field in this record)
pfield (field, buf) /* lock this record,
update record,
write to disk,
unlock this record */
This is a *lot* of overhead, especially when one updates, oh, say
100 records with 50 fields each.
Ok, let me partially absolve Unify. Our system is Version 7, which
just recently gained the Bass kernal-locking stuff. In this version of
Unify, it playes with a (shudder) lockfile. Of course, changing to kernal
locking would speedup updates by a factor of 2 (maybe 3?).
Throughout Unify, it assumes that there is only ONE printer,
and that there is only ONE form on that printer, the correct one for
this print job. So, what happens when finance wants to print an
edit register on green-bar, print checks on check-stock, print a
check-register, Jerry wants to print on letterhead, condensed, and
I want to print shipping labels? Well, you resort to kludges, just
like we did (if you *really* want it, I'll describe how we did it).
Now, the bugs. We still occasionally have problems with the B-trees
becoming corrupt, and we've had one record-type to completely barf big-
time. To the point of: write the data into an ascii file, deleting
the record-type, reconfiguring the database, re-creating the record-type,
reconfiguring, checking the ascii file for weird chars, inserting the
data, and it still weirds out (error in physrec, I believe). Even
leaving the bad record-type in, creating a new record-type (same
field types & lengths, different names) didn't help.
And, as far as defensive programming is concerned, some do and some
don't. As long as you give it just what is required, it works fine.
But, if a parameter is neglected, or misplaced, instead of causing
an error, it proceeds to try to process the data. Example: in
checking the abovementioned ascii file for bad chars, we just deleted
illegal chars with tr(1). Stupidly, I also threw away all newlines.
When fed to DBLOAD, it tried to insert it. No complaints about
too many fields on this line, line too long, or anything. Ok, I know
that I screwed up, but I'm human, and DBLOAD *should* have caught it.
Well, some of these are pretty picky, and I don't expect things
like pfield to change. But, a way to specify printer and form would
be nice for RPT scripts. And tracking down those last elusive bugs
with the B-trees and screwy record-types would shut me up. I'm sure,
now that this article is posted, that shutting me up is worth something.
--
Daniel S. Cox
({siesmo!gatech|ihnp4!akgua}!itm!danny)