Below is a list of questions, that im often asked
about LEAP. I hope I have provided answers to some of
your questions.
If theres anything else you want to ask post it in the mailing list or contact me directly. |
Operations in
LEAP |
How to list the attributes of a relation?
Why doesn't "join (relation1) (relation2)"
work (as expected)?
Why are temporary relations always
deleted?
How can I reduce the space wasted
in a relation?
How do I update and delete tuples
in a relation?
|
| Compilation Issues
|
How do I compile in the readline
libraries?
How do I enable/disable debugging?
|
| Installation Issues
|
How do I create the standard database
set?
How do I apply a patch?
|
| Distribution Issues |
How much does LEAP cost?
Is there a Windows version?
|
| When can I expect a particular feature? |
SQL, ODBC and JDBC
|
|
Documentation Issues
|
Where can I find out more information
about LEAP?
|
| Mailing List |
Subscribing/Unsubscribing
Posting
|
|
| Operations in
LEAP |
How to list the attributes of a relation?
|
Use the 'describe'
command, eg. 'describe leaprel' returns:
Type Sz.
Name
----------- --- ----------
STRING 25
NAME
STRING 25
FNAME
BOOLEAN 1 TEMP
INTEGER 4
NOATTRIBS
BOOLEAN 1 UPDATED
BOOLEAN 1 SYSTEM
Relation leaprel returned.
|
Why doesn't 'join (relation1) (relation2)' operator
work (as expected)?
|
Joins require
conditions. Fundamentally a join is a product followed by
a select. The full form of a join is thus:
join (rel) (rel) (condition)
LEAP
will (normally) look in two places for a condition - the first
is the command line, and each expression must by enclosed in brackets.
Values must be enclosed in quotes, eg.
join (rel1)
(rel2) (rel1.attrib=rel2.attrib)
join (rel1) (rel2) ((rel1.attrib=rel2.attrib)and(rel2.attrib='2'))
If a condition
is not specified, LEAP will look in the relship relation,
which has eight attributes:
frelation
- 'foreign' relation
prelation - 'primary' relation
fkey[1-3] - 'foreign' relation attributes 1, 2 and 3
pkey[1-3] - 'primary' relation attributes 1, 2 and 3
Essentially,
specify the primary key and it's attributes, and the foreign key
and it's attributes. For example, the LEAP system relation
'leapattributes' contains an attribute 'RELATION' which
is a relation name. This is the foreign key, to the primary
key 'NAME' in the relation 'leaprel'.
'leapattributes'
defines all the attributes in a relation and 'leaprel' defines
all the relations in a database.
By referencing
the relship table, the join operator can derive the condition
automatically, ie.
((leaprel.NAME=leapattributes.RELATION))
There is a
third method LEAP will use, and this occurs only if
no condition can be derived from the command line, or the productjoin
status is set on (or --product-join is specified on the
shell command prompt). In this scenario, LEAP will
emulate SQL behaviour, which is to perform a simple 'PRODUCT'
on the two relations specified (ie. the product, without
the join).
|
Why are temporary relations always deleted?
|
Temporary
relations are (by default) always deleted to remove the clutter
from the database. If this is not acceptable, you can do one of
two things:
|
Set the temporary setting 'off' - temporary indicates
whether temporary relations are to be deleted. By default
it is on.
Change the status - 'change relation' - This will
update the temporary status of a relation such that it is
a permanent relation.
|
How can I reduce the space wasted in a relation?
|
Relations can contain a great deal of wasted space.
This is caused by the update and delete operators, which
only mark tuples as deleted - the space isn't reclaimed.
New to LEAP 1.2.5 is the 'compact' operator - which
will remove this space. The worst offender is invariable
'leaprel' or 'leapattributes'. You can see the contents
of a relation (including the 'deleted' tuples) by running the
'dump' command (or the dumprel program at the command line). To
compress the space:
compact (relation)
Any errors encountered will be reported. In later
releases of LEAP, the compression of wasted space
will become an automated feature on shutdown.
|
How do I update and delete tuples in a relationship?
|
LEAP now allows existing tuples to be easily
updated and deleted.
Deleting tuples takes the form: delete (relation) (condition)
This will
search the relation specified for any tuples that match the
specified condition. On encountering such a tuple, the tuple is
marked as deleted. The condition takes the form of a condition
you'd use in the select or join operator, and can refer
to attributes in the relation, or to always true (or false)
statements if required.
To delete
an ENTIRE relation use the 'delrel' command. Deleting all
of the tuples in a relation will leave an empty relation.
Updating tuples
takes the form: update (relation) (condition) (update_statements)
The first
three components of the update command are identical to
the delete operator. The last component is new - This is where
the attributes to be updated are specified, along with the values
to update them with, eg.
update (r)
(a='4') (a='5')
The relation
'r' is updated, where attribute 'a' equals '4', and where
this condition is true, set the attribute to '5'.
Its' possible
to specify multiple updates, by seperating the statements
with commas, eg.
update (r)
(a='4') (b='1',c='2')
Current restrictions
with the update operator are that you can only set values
to explicit values - it's not currently possible to set
it to values elsewhere in the updated tuple; It's also not possible
to update it based on a condition or value crossing relations
(as you can do in SQL). These shortcomings will be addressed
in a later release.
|
|
| Compilation
Issues |
How do I compile in the readline libraries?
|
LEAP
supports the readline libraries if they are installed. The readline
libraries allow command line history and command editing. Versions
2.0 and2.1 are known to work.
Unlike many other packages, the readline libraries are *NOT*
included in the default LEAP default distribution.
See http://www.gnu.org
for a copy.
In order to
compile LEAP with the readline libraries, run configure
with --with-readline, and set CPPFLAGS to include the include
PATH (and -I flag). Sun systems (and others) will also need
LD_LIBRARY_PATH to be set:
eg. if the
readline libraries are included in /usr/local/include (and
you're using a bourne (sh) compatible shell:
cd src
./configure --with-readline
CPPFLAGS=-I/usr/local/include
export CPPFLAGS
make depend
make
csh users:
setenv CPPFLAGS -I/usr/local/include
Sun users:
LD_LIBRARY_PATH /usr/local/lib
Linking with
incorrect library search path will fail. If LD_LIBRARY_PATH
is not supported, you may need to edit LDFLAGS to include: -L<path>
-
with <path> being the path to the libraries.
|
How do I enable/disable debugging?
|
Debugging
requires a particular function (do_debug) to be called at various
points in the code. Even when the debug level is 0 (no debugging),
this stilleats CPU cycles. If you're not keen to have this
time wasted, run configure with --disable-debug, and recompile.
This option can be added with others.
NB - The CPU time used is not huge, certainly compared to
disk i/o.
|
|
| Installation
Issues |
How do I create standard database set?
|
Normal installation
of the basic database set (master, tempdb, user and a few
example databases) can be achieved by typing make install
- However, the WIndows distribution might require this to
be done manually if long filenames were not created when uncompressing
the distribution archive (Winzip is recommended rather than
pkunzip).
The command to install LEAP is:
./leap --configure
../scripts/install.src
This is the
command that is executed by 'make install' - It starts LEAP
up and configures the databases with the various commands
in the install.src script.
|
How do I apply a patch?
|
LEAP
bug fixes are distributed with patches. If you're using a Un*x
system, it's generally very easy to apply a patch, which saves
having to download the complete distribution all over again.
For example, to apply the 1.2.3 patch to the 1.2.2 distribution
you previously downloaded:
|
Download the 1.2.3 patch
Save the patch to the base of the 1.2.2 installation
Unpackage the package (It's usually compressed
with gzip), and rename it leap_patch_122_123
Run the patch command: patch -p1 < ./leap_patch_122_123
|
The patch
command is a freely available piece of software, written
by Larry Wall (of perl fame). A link is available on the LEAP
web pages.
|
|
| Distribution
Issues |
How much does
LEAP cost?
|
LEAP
is distributed under the terms of the GNU
General Public License. This license should be carefully studied
if you indend to make use of any part of LEAP. You're not
required to pay the author anything to use LEAP.
However, if you feel like it, do so, but it's entirely at
your own discretion.
|
Is there a Windows
version?
|
There is now
a Windows 95/NT version, offering much of the standard functionality
you expect in Windows - command line history, and adjustable
window size and fonts. See the LEAP web page for
full details.
|
|
| When can I expect a particular feature? |
SQL, ODBC and
JDBC
|
Support for SQL was never included in the original
design for LEAP. LEAP was designed as an educational
tool for students of relational algebra. However, the students
of database theory courses need to be prepared for what
the real world demands - and as far as database query languages
go, this is SQL.
Before talking about LEAPs aspirations, it's worth
making it clear that there are currently plenty of other
SQL based databases available under the GNU GPL that might
be more appropriate for your purposes. Be careful to check
what the license agreement is, and whether you want access
to the source code.
LEAP will enventually include support for
an SQL subset, but before this can be offered, some major
restructurnig is necessary of the source code. LEAP's
parser (the part of the software that translates a simple
command into an internal memory structure) is not capable
of flexibly supporting both the relational algebra, and
SQL. The next major release of LEAP (1.3/1.4) will
use lex/yacc to support the existing query language. Once this
has been successfully implemented, and debugged, it should be
a simple process to slot in the lex/yacc definition for SQL
(writing it is a different matter). Some of the more advanced
features of SQL will drive new operators/mechanisms in
LEAP.
Consequently, LEAP does not currently support JDBC or ODBC
connectivity, nor will it for some time to come.
|
|
| Documentation Issues |
Where can I
find out more information about LEAP?
|
LEAP's User documentation is included in the normal
distribution. The website contains a
copy too.
For an overview of the LEAP architecture, the
original LEAP design document is available from the Sourceforge
download page - This is the submitted project write
up of the original Pascal version, which has been significantly
superseded by the current version.
A book has recently been released, which includes
a chapter on LEAP. "Theory and Practice
of Relational Databases", 2nd Edition, by Stefan Stanczyk.
Bob Champion and Richard Leyton, Routledge, 2001. For more detail,
see the books accompanying website at http://www.theorypractice.org
|
| Mailing List |
There is a
mailing list for all aspects of LEAP. When LEAP
is installed it will offer to subscribe you to it. It's low volume
(it's primarily announcement based, but other postings do
appear). As of January 1999, it a fully moderated list.
This has become necessary due to the high volume of spam
(unsolicited, and unrelated e-mail) that has been appearing
on the list. Hopefully it will be possible to return to
an unmoderated list should the volume of spam decrease.
|
Subscribing/Unsubscribing
|
To subscribe
or unsubscribe, visit http://lists.sourceforge.net/lists/listinfo/leap-announce
|
Posting to the List
|
You
must first subscribe to the mailing list. Send an e-mail to leap-announce@lists.sourceforge.net
- note that the list is moderated, and your post
needs to be approved by the list moderator first. The moderator
is the LEAP author, Richard Leyton.
|
|
|
