1 Mnemosyne - Release Notes
This document describes the changes made to the Mnemosyne application. The intention of this document is to list all incompatibilities as well as all the enhancements, bugs and adjustments that have been noted for each previous release of Mnemosyne. Each release thus constitutes one section in this document. The title of each section is the Mnemosyne version number.
1.1 Mnemosyne 1.2.5
1.1.1 Improvements and new features
1.1.2 Fixed Bugs and malfunctions
- Complex queries failed (looped forever) if there where more 1000 entries in the table
OTP Id: OTP-3656
Aux Id: Seq-4842
1.2 Mnemosyne 1.2.4
1.2.1 Improvements and new features
1.2.2 Fixed Bugs and malfunctions
- Mnemosyne failed to do proper variable substitution in queries with records constructions where a field was assigned the value of variable. The generate code of the failure was not compile-able.
OTP id: OTP-3365
- Mnemosyne generated doubled code for record handling, this has been removed.
1.3 Mnemosyne 1.2.3
1.3.1 Improvements and new features
1.3.2 Fixed Bugs and malfunctions
- A proper EXIT message is generated if mnemosyne is not started, when evaluting a query.
OTP id: OTP-3197
1.4 Mnemosyne 1.2.2
1.4.1 Improvements and new features
1.4.2 Fixed Bugs and malfunctions
- Fixes in documentation.
- Mnemosyne could crash if elements where deleted when mnemosyne scanned a table
OTP id: OTP-3275
Aux Id: Seq 3945
1.5 Mnemosyne 1.2.1
1.5.1 Improvements and new features
1.5.2 Fixed Bugs and malfunctions
Mnemosyne have been modified to handle the new exit codes introduced in OTP-R5C.
1.6 Mnemosyne 1.1
Some internal things have changed (see below) as well as some new functionality. This means that the queries have to be recompiled.
1.6.1 Improvements and new features
- A new two-argument table generator. Starting from Mnesia 3.4, table names and the associated record type need not to be the same, ie there can me multiple tables with the same record type. In Mnemosyne this is specified as a table generator with arity 2. For exmaple the following uses data from table
a
with record typeb
.
X <- table (a,b)The oldtable(Name)
still exists and defaults totable(Name,Name)
- Rules that have a return type other than the name of the rule (default), can be declared by using a two argument rule declaration. The previous way of declaring this (using a special
argtype
declaration) still work but the new way is preferred.
1.6.2 Fixed Bugs and malfunctions
- It is now possible to use nested records inside Mnemosyne in the same way as in Erlang in general, for example the following is ok inside a query:
(X#a.b)#c.d
. The inner#a
is not needed if the type ofX
is known.
- When generating new records in a query the default arguments of the record are properly used, including eventual function calls etc.
1.6.3 Incompatibilities
Some incorrect queries are detected in Erlang compile time rather then during setup / execution in runtime.
The negation operator,
not
, that was present in earlier versions has been removed. The main reason is that the semantics is unclear in many cases, and almost all questions have no need for a negation. The typical use of negation was something like the following code fragment:query [ X || X <- table (employee), not X <- rule (chiefs) ] endHere, the query variable,
X
, is first bound and then a negation is applied. Usages such as these can often be rewritten by first evaluating the negation in a separate query and then the rest of the query. Asuming the query is evaluated usingeval
the above could be written:NegQ = query [ X || X <- rule (chiefs) ] end, NegAns = mnemosyne:eval (NegQ), Q = query [ X || X <- table(tab), not lists:member (X, NegAns) ], Ans = mnemosyne:eval (Q)Note that the not used above is Erlangs own not, not the (old) mnemosyne
not
.Also note that the above code is not less efficient then the previous versions (that used
not
) since the whole negation has to be evaluated.1.6.4 Known bugs and problems
No new ones. See earlier release notes.
1.7 Mnemosyne 1.0.1
This release is a minor release and the release notes describes the difference between version 1.0.1 and version 1.0 of Mnemosyne.
1.7.1 Improvements and new features
- The documentation has been enhanced.
1.7.2 Fixed Bugs and malfunctions
1.7.3 Incompatibilities
1.7.4 Known bugs and problems
No new ones. See earlier release notes.
1.8 Mnemosyne 1.0
This is the first release of Mnemosyne as an own application, separate from the Mnesia DBMS Engine. The Mnemosyne application must be used in conjunction with Mnesia 3.0 or later.
1.8.1 Improvements and new features
1.8.2 Fixed Bugs and malfunctions
1.8.3 Incompatibilities
Mnemosyne
has been separated from theMnesia
application and this has some minor implications:
- The compiler directive:
-include_lib("mnesia/include/mnemosyne.hrl").that was mandatory in all Erlang modules containing embeddedMnemosyne
queries has been replaced with:
-include_lib("mnemosyne/include/mnemosyne.hrl").During the interim period, both compiler directives will be supported. However, in a future release the backward compatibility directive will be removed from Mnesia.
- The Mnemosyne application must be started before any query evaluation may be performed. Earlier, when Mnemosyne was a part of the Mnesia application, Mnemosyne was automatically started as an embedded part of Mnesia, this is not the case anymore. Now Mnemosyne must be started with
application:start(mnemosyne)
, when Mnesia is started.
However, a temporary configuration parameterembedded_mnemosyne
has been added to Mnesia in order to make it possible to access the automatic start of Mnemosyne. By defaultembedded_mnemosyne
is set tofalse
, but if it is set totrue
Mnesia will start Mnemosyne as a supervised part of the Mnesia application as it did in previous releases.
1.8.4 Known bugs and problems
- The evaluation of Mnemosyne queries has undefined behavior if they are used in conjunction with nested transactions.
- The evaluation of Mnemosyne queries has an undefined behavior if the involved tables are updated after the cursor has been initiated.
- Mnemosyne queries should not be used on disc-only tables since the optimizer can't handle such tables.