GNU Info

(slib.info)Unresolved Issues

---

Next: Database Utilities Prev: Catalog Representation Up: Relational Database

---

Enter node , (file) or (file)node

Unresolved Issues
-----------------

  Although `rdms.scm' is not large, I found it very difficult to write
(six rewrites).  I am not aware of any other examples of a generalized
relational system (although there is little new in CS).  I left out
several aspects of the Relational model in order to simplify the job.
The major features lacking (which might be addressed portably) are
views, transaction boundaries, and protection.

  Protection needs a model for specifying priveledges.  Given how
operations are accessed from handles it should not be difficult to
restrict table accesses to those allowed for that user.

  The system catalog has a field called `view-procedure'.  This should
allow a purely functional implementation of views.  This will work but
is unsatisfying for views resulting from a "select"ion (subset of
rows); for whole table operations it will not be possible to reduce the
number of keys scanned over when the selection is specified only by an
opaque procedure.

  Transaction boundaries present the most intriguing area.  Transaction
boundaries are actually a feature of the "Comprehensive Language" of the
Relational database and not of the database.  Scheme would seem to
provide the opportunity for an extremely clean semantics for transaction
boundaries since the builtin procedures with side effects are small in
number and easily identified.

  These side-effect builtin procedures might all be portably redefined
to versions which properly handled transactions.  Compiled library
routines would need to be recompiled as well.  Many system extensions
(delete-file, system, etc.) would also need to be redefined.

There are 2 scope issues that must be resolved for multiprocess
transaction boundaries:

Process scope
     The actions captured by a transaction should be only for the
     process which invoked the start of transaction.  Although standard
     Scheme does not provide process primitives as such, `dynamic-wind'
     would provide a workable hook into process switching for many
     implementations.

Shared utilities with state
     Some shared utilities have state which should _not_ be part of a
     transaction.  An example would be calling a pseudo-random number
     generator.  If the success of a transaction depended on the
     pseudo-random number and failed, the state of the generator would
     be set back.  Subsequent calls would keep returning the same
     number and keep failing.

     Pseudo-random number generators are not reentrant; thus they would
     require locks in order to operate properly in a multiprocess
     environment.  Are all examples of utilities whose state should not
     be part of transactions also non-reentrant?  If so, perhaps
     suspending transaction capture for the duration of locks would
     solve this problem.