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.