Limitations
This page explains the limitations of Rel359 and gives some idea of whether or not
they might be fixed one day. However, to be honest, I am unlikely to find time to
fix any of them!
Domains
-
Rel359 does not support domains, it only
supports simple types of CHAR, INTEGER & RATIONAL. If you have installed
the Java SDK then you should be able create additional custom types but this
has not been tested in Rel359 and is not documented on this site.
Altough the M359 Language uses domains, it never defines them formally, nor does
it describe a language for creating them. In fact page 16 of M359 Block 2 states
that "a domain is a theoretical construct. We are not, at this point, interested
in how a domain might be implemented". Therefore I
have no plans to fix this limitation, because there is no definition of
what to implement.
Dates
-
Rel359 does not support dates. Dates are treated as strings and therefore
don't sort or compare properly unless entered using a format such at
ISO 8601 (YYYY-MM-DD).
There is a chance I may investigate whether I can fix this limitation.
Foreign Keys
-
Rel359 does not support foreign keys.
Foreign keys are described in the text as if they are something specific
to a given relation and are written in terms of
foreign key attribute references relation
But page 26 of M359 Block 2 explicitly states that the foreign key "can be
matched with any candidate key rather than just the primary key of the
relation that it references" and the syntax for foreign keys shown above
does not include anything to specify the particular key to reference in
the referenced relation so I would argue that it is not possible create an
implementation that could correctly reference any key without specifying
which key to reference.
Extending the syntax to support foreign keys fully would mean that Rel359 would
not be implementing the M359 Langauge, so there seems to be little benefit in
attempting to come up with an implementation for foriegn keys when constraints
can be used instead.
I have no plans to fix this limitation.
Constraints
-
Rel359 only supports a limited number of M359 style constraints.
(Currently upto 1000 M359 style constraints are supported.)
In the M359 Language constraints are defined in the context of a relation and are not named
but in Tutorial D, they are named. Rel therefore stored the details of the constraints
in the a relation and used the name as the primary key. It would have been very complex to try
to implement contraints in Rel359 any other way. Furthermore constraints need to be named so
that they can be identified if you want to delete them later. Rel359 therefore automatically
selects a name when you create a constraint using the M359 Language syntax.
The easist way to provide a unique name for each constaint was to create a relation containing
a large number of possible names and then use relational algebra to select a name that hadn't
been used already. The downside of this approach is that you can run out of names if you try
to create more constraints than there are names in the list of possible names.
This limited number of names for constraints is held in the sys.CandidateNames relation so you
can insert additional names should you really need to, but 1000 names should be more than
suffcient for the purposes of studying M359.
I have no plans to fix this limitation.
Comments
-
Rel359 does not support comments when defining relations.
The M359 Language uses comments defined within braces: {comment text}. Tutorial D
and hence Rel and Rel359 use this notation for defining tuples. Using
this notation for comments would therefore be difficult and so
I have no plans to fix this limitation.
Imperative statements
-
Rel359 requires imperative statements to be terminated with a semicolon.
Requiring a semicolon at the end of imperative statements is an annoying difference
between the M359 Language and Rel359's implementation and could potentially mislead
unwarey students. However, unlike most of the changes I made to Rel in creating
Rel359, this is not just a language change. The semicolon is used to diferentiate
between statements throughout the program, from the front end client browser to the
database engine, hence changing this feature may be difficult.
One advantage of this feature is that it allows you to create a script file containing
several imperative statements separated by semicolons. However
there is a chance I may investigate whether I can fix this limitation.
Database backup
-
The Backup button does not work in Rel359.
There is a button marked "Backup" in Rel359 which should save your database to
script files so that it can be reloaded later. Unfortunately I forgot about it when I
created Rel359 and so it doesn't work but
there is a chance I may investigate whether I can fix this limitation.