Current Limitations and Work in Progress

All limitations described below will be addressed in future versions of Rel.

Limitations – Rel Server

Nested Transactions: The current version of the storage engine – Oracle’s (formerly SleepyCat Software’s) Java edition of the Berkeley DB – supports low level nested transactions within the API, but throws an exception at runtime to indicate the feature is not implemented yet. If this condition persists, a different storage engine will have to be used. If needed, this will probably be the C version of the Berkeley DB, but a custom storage engine will almost certainly replace it at some point.

As a result, nested transactions that ABORT cause their parent transactions to abort. A nested COMMIT does nothing.

User-defined types: Multiple-inheritance is not yet supported. This is a work in progress slated for deployment in summer 2013.

KEY specifications on virtual relvars: KEY constraints on VIRTUAL relvars (views) are accepted but will be ignored.

Operators: The UPDATES parameter modifier is not implemented yet.

Flow control: The LEAVE statement is not implemented yet.

Optimisation: There is none, anywhere, of any kind, except a minimal effort has been made to achieve acceptable JOIN performance. However, since “premature optimisation is the root of all evil,” (C. A. R. Hoare) this cannot be considered entirely a bad thing. Future versions of Rel will implement appropriate optimisation mechanisms.

Substitution operator: Due to a quirk in the parser, the UPDATE or substitution operator, which should be specified as, for example…

UPDATE expr (x := x + 1)

…must be specified as:

UPDATE (expr) (x := x + 1)

Note the parentheses around the relation or tuple expression ‘expr’. Without the parentheses, the parser will generate an error message.

This will be corrected in a future update.

Note that this limitation does not apply to the UPDATE statement.