ANNOUNCE: Rel version 3.013 now available!
This release of Rel, an implementation of Date & Darwen's Tutorial D database language, improves the user interface, fixes some bugs, adds support for outer joins, and significantly reduces the size of the Rel distribution whilst improving startup speed.
The following enhancements have been made:
- The Rel user interface (known as DBrowser) provides same familiar interface but now has significantly fewer Eclipse framework dependencies. The result is a smaller distribution and improved start-up time.
- DBrowser: Export option dropped from relvar edit grids, as there are other, better facilities for exporting to Excel available on right-click menus, etc.
- DBrowser: Under Preferences, moved alternate output display option to Display tab.
- DBrowser: Improved handling of icon resizing via Preferences. On MacOS, all icon sizes change without needing to restart.
- DBrowser: Preferences data is no longer stored in Rel application directory; now stored in user's home directory. This allows keeping preferences across Rel updates.
- DBrowser now supports "remote only" mode where only connections to remote databases are possible. To enable, delete rel0*.jar (e.g. rel0000.jar), RelDBMS.jar, and RelTest.jar from lib/rel.
- DBrowser '+' tab now provides list of recently-used databases and means to delete entries. As a result, management entries removed from main menu.
- DBrowser: Tweaks to display of RVAs to improve readability.
- DBrowser: Now provides option to create and restore a database from a backup as a unified operation.
- Client library: Decoupled Server/ServerV0000 from Client to permit use of relclient.jar on its own (plus relshared.jar) to facilitate developing purely remote clients.
- Rel: Added p LEFT JOIN q which returns
TUPLE {Matched p JOIN q, Missing p NOT MATCHING q}
- Rel: Added p RIGHT JOIN q which returns
TUPLE {Matched p JOIN q, Missing q NOT MATCHING p}
- Rel: Added p FULL JOIN q which returns
TUPLE {
Matched p JOIN q,
MissingLeft p NOT MATCHING q,
MissingRight q NOT MATCHING p
}
- Build: Module jars now generated via Ant build files; product build scripts now generate all jars.
The following bugs have been fixed:
- DBrowser: The 'comment' visualiser in Rev now handles carriage return correctly on all platforms.
- DBrowser: Saving a script with escape chars, e.g., \\blah, loaded as \blah. Fixed.
- DBrowser: Resizing the Rel window whilst in relvar Edit mode caused odd problems, such as the content not re-sizing, scrollbars disappearing, etc. Fixed.
- DBrowser: Graphical editing of RVA value did not work due to failure to launch RVA editor. Fixed.
- DBrowser/Client: Fixed TUPLE of RVA display problems.
- Rel: parallel RENAME now supported. E.g.,
TUPLE {x 10, y 20, z 30} RENAME {x AS y, y AS x} works.
Case #203 fixed.
- Rel: This threw a fatal error:
RELATION {TUPLE {RVA RELATION {TUPLE {K 1}}}}
EXTEND {RR := RVA RANK (ASC K AS R)}
Fixed.
For more information, or to download Rel, go to https://reldb.org
I showed these outer join bullets to Chris Date:
- Rel: Added p LEFT JOIN q which returns
TUPLE {Matched p JOIN q, Missing p NOT MATCHING q}
- Rel: Added p RIGHT JOIN q which returns
TUPLE {Matched p JOIN q, Missing q NOT MATCHING p}
- Rel: Added p FULL JOIN q which returns
TUPLE {
Matched p JOIN q,
MissingLeft p NOT MATCHING q,
MissingRight q NOT MATCHING p
}
He responded:
"My immediate reaction to Dave's outer join ops is: Not bad. We realized many, many years ago -- I can probably search out the reference if necessary -- that the real problem with conventional outer join is that it produces a set of relations with different headings and predicates. At that time, however, we hadn't realized that the DB (set of relvars) is really a tuplevar, and a DB value (set of relations) is really a tuple -- so we hadn't seen how to bring in "set of relations" as a construct in its own right. Now we do see, I wonder idly whether that construct needs to be promoted as some kind of "first class object." PS: Of course, your multirelations fit right in here too. My immediate reaction to Dave's outer join ops is: Not bad. We realized many, many years ago -- I can probably search out the reference if necessary -- that the real problem with conventional outer join is that it produces a set of relations with different headings and predicates. At that time, however, we hadn't realized that the DB (set of relvars) is really a tuplevar, and a DB value (set of relations) is really a tuple -- so we hadn't seen how to bring in "set of relations" as a construct in its own right. Now we do see, I wonder idly whether that construct needs to be promoted as some kind of "first class object." PS: Of course, your multirelations fit right in here too."
Regarding promotion of the construct to "first class", I wonder what he's thinking of. Special operators on tuples whose attribute values are all relations? I note that in general the same relation might appear more than once in such a tuple, as would happen with Dave's operators in the special case where p and q are of the same heading and both are empty, for example. So we don't always have a strict set of relations. Any ideas for such operators?
Hugh
Quote from Hugh on December 8, 2018, 12:56 pmI showed these outer join bullets to Chris Date:
"...At that time, however, we hadn't realized that the DB (set of relvars) is really a tuplevar, and a DB value (set of relations) is really a tuple -- so we hadn't seen how to bring in "set of relations" as a construct in its own right. Now we do see, I wonder idly whether that construct needs to be promoted as some kind of 'first class object.'"
Regarding promotion of the construct to "first class", I wonder what he's thinking of. Special operators on tuples whose attribute values are all relations? I note that in general the same relation might appear more than once in such a tuple, as would happen with Dave's operators in the special case where p and q are of the same heading and both are empty, for example. So we don't always have a strict set of relations. Any ideas for such operators?
You (and Chris) mean a tuple of RVAs being promoted to a distinct construct -- say, a TOR (Tuple of Relations) -- a category of constructs to which both a database and the return value of FULL|LEFT|RIGHT JOIN belongs?
I'm not (yet) convinced a tuple of RVAs is special enough to warrant being a distinct construct, or that it needs special operators beyond those already designated for tuples.
I would have preferred to see a single relation having ZOO attributes instead of a tuple containing multiple relations.
The way I see it, a SQL column that allows NULLs corresponds to a ZOO attribute in a TTM relation variable. A join on a nullable column would require the transformation of all operands first. For instance,
A REL {Y INT}, B REL {X INT, Y REL {Y INT}}
A JOIN B would require A to be transformed to A {Y REL {Y INT}} first, and then the result would be of type REL {X INT, Y REL {Y INT}}
Outer joins would require attributes that are not common to be "ZOOd":
P LEFT JOIN Q would require the attributes in Q that don't appear in P to be ZOOd.
P RIGHT JOIN Q would require the attributes in P that don't appear in Q to be ZOOd.
P FULL JOIN Q would require the attributes that don't appear in both P and Q to be ZOOd.
This would be in addition to any transformation required for attributes in common.
Just my thoughts,
Brian
Quote from Brian S on December 9, 2018, 8:58 amI would have preferred to see a single relation having ZOO attributes instead of a tuple containing multiple relations.
What would be the benefit(s) of your ZOO attribute approach, compared to the tuple-of-RVAs approach I've used?
Quote from Dave Voorhis on December 9, 2018, 11:48 amQuote from Brian S on December 9, 2018, 8:58 amI would have preferred to see a single relation having ZOO attributes instead of a tuple containing multiple relations.
What would be the benefit(s) of your ZOO attribute approach, compared to the tuple-of-RVAs approach I've used?
Many times a left/right outer joins is used, the ultimate purpose is to display members of either matching/missing in one single tabular list ordered by some identifier common between the two and with the "missing" attribute values appropriately rendered as blank cells. That's still quite some work to do if the input is your (our) separate relations.
So the scenario seems to be begging for a generic ASZOO(...) operator capable of taking the results of your (our) matching-missing two-tuple and produce Brian's requested single relation with ZOOs.
Which then also begs the question of doing the transformation in the opposite direction.
Quote from Erwin on December 9, 2018, 7:38 pmQuote from Dave Voorhis on December 9, 2018, 11:48 amQuote from Brian S on December 9, 2018, 8:58 amI would have preferred to see a single relation having ZOO attributes instead of a tuple containing multiple relations.
What would be the benefit(s) of your ZOO attribute approach, compared to the tuple-of-RVAs approach I've used?
Many times a left/right outer joins is used, the ultimate purpose is to display members of either matching/missing in one single tabular list ordered by some identifier common between the two and with the "missing" attribute values appropriately rendered as blank cells. That's still quite some work to do if the input is your (our) separate relations.
I suppose that's true if you're generating a unified tabular display unifying both matching and missed values. I generally try to avoid it, so I would (for example) display the customers with phone numbers in one list and customers without phone numbers in another.
To display both in the same list, each ZOO attribute would have to be converted to a displayable format suitable for use with the usual UI widgets. That would -- I think -- involve much the same effort (and pretty much the same notional kind of operations) as converting tuple-of-RVAs to some displayable format suitable for use with the usual UI widgets.
Quote from Dave Voorhis on December 9, 2018, 11:48 amQuote from Brian S on December 9, 2018, 8:58 amI would have preferred to see a single relation having ZOO attributes instead of a tuple containing multiple relations.
What would be the benefit(s) of your ZOO attribute approach, compared to the tuple-of-RVAs approach I've used?
Multiple joins
A LEFT OUTER JOIN B LEFT OUTER JOIN C LEFT OUTER JOIN D, etc.
I'm sure you've seen SQL queries with several outer joins targeting multiple tables which yield a single result set. How would you make that happen with your solution that yields a tuple containing multiple relations for each outer join? While I'm sure it can be done, it certainly wouldn't be intuitive for practitioners with even a cursory understanding of SQL.
Quote from Brian S on December 10, 2018, 2:03 amQuote from Dave Voorhis on December 9, 2018, 11:48 amQuote from Brian S on December 9, 2018, 8:58 amI would have preferred to see a single relation having ZOO attributes instead of a tuple containing multiple relations.
What would be the benefit(s) of your ZOO attribute approach, compared to the tuple-of-RVAs approach I've used?
Multiple joins
A LEFT OUTER JOIN B LEFT OUTER JOIN C LEFT OUTER JOIN D, etc.
I'm sure you've seen SQL queries with several outer joins targeting multiple tables which yield a single result set. How would you make that happen with your solution that yields a tuple containing multiple relations for each outer join? While I'm sure it can be done, it certainly wouldn't be intuitive for practitioners with even a cursory understanding of SQL.
A chain of multiple LEFT OUTER joins all resulting in a single NULL-laden1 result is very much a SQLism. How likely is a practitioner with even a cursory understanding of a D likely to want to implement it?
--
[1] Not only NULL-laden, but ambiguous -- was the NULL in the original data, or a result of the outer join?
Quote from Dave Voorhis on December 10, 2018, 10:56 am[1] Not only NULL-laden, but ambiguous -- was the NULL in the original data, or a result of the outer join?
Surely, "NULL in the original data" cannot occur if we're doing this in Rel ?