[VPM] ANNOUNCE - Language::MuldisD v0.11.0 released

Darren Duncan darren at DarrenDuncan.net
Mon Nov 19 22:38:31 PST 2007


I am pleased to announce the release of Language::MuldisD 
official/unembraced version 0.11.0 on CPAN.  You can see it now, with 
nicely HTMLized documentation, at:


All the important changes since release 0.9.0 were in the file 
Basics.pod, mainly its bottom half from ENVIRONMENT downwards:

1.  A Muldis D DBMS / virtual machine is now officially 
multi-threaded rather than single-threaded; that is, it now houses 
multiple concurrent processes where each is its own context for 
transactions.  A corollary to this is that Muldis D now includes 
autonomous transaction support.  Implementations of Muldis D can use 
either lightweight threads or heavyweight processes or fake either as 
they see fit; in any event, each in-DBMS process is isolated from the 

One consequence of this change is that Muldis D can now provide the 
commonly used state-remembering sequence generators feature where the 
generator doesn't issue repeated values following a rollback of a 
transaction within which it issued values.  To be more specific, 
users can choose which of the behaviours they want if they can't or 
don't want to invoke the generator prior to the start of the main 
transaction.  If repeat values are okay or desired, then they invoke 
the sequence generator within the main transaction like before.  To 
avoid repeat values after invoking the generator within a main 
transaction, users can instead invoke it within a separate autonomous 
transaction which commits regardless of what the main transaction 

If you wonder why that makes a difference, keep in mind that Muldis D 
prescribes that the whole virtual machine as seen by a process is 
synchronized for transactions, and that everything in it, 
data-definition and sequence generators included, are subject to 
transactions and can be rolled back (which is also how SQLite works). 
Previously, the whole VM period was one main transaction at a time.

Another use for autonomy is if you want to reliably commit a log of 
some operation that will be rolled back prior to rolling it back.

A more broad use for the change is that a Muldis D DBMS can more 
effectively serve as a database server with multiple independent 
clients like Oracle et al do.

Note that this feature is in addition to the implicit auto-threading 
ability that implementations could choose to use before to speed up 
parallelizable order-agnostic set/relational function operations.

2.  An in-DBMS entity top-level namespace was added to house all 
system-defined types and routines that are implementation-specific 
and non-standard, so that the standard Muldis D language can be free 
to evolve without worrying about conflicts with third-party 
extensions.  So anything starting with 'sys.' is part of the 
standard, and anything starting with 'imp.' is not.  The broadest 
namespace for user-defined entities is now 'fed.' (federation).

3.  All user-defined types, routines, relvars in a database are now 
grouped under the privatizing 'package' namespaces, which are under 
the multi-level supporting 'depot' namespaces.  So it is easier to 
organize which things are public to everyone and which are private to 
just use in the same package; that is, we more easily distinguish 
between persistable public/private types, routines, and relvars.

4.  It is now normal (and essentially required) to store all database 
referencing code in the database as stored routines, and the rest of 
your application just invokes those directly.  As a corollary, you 
can define databases which contain just code, and are effectively 
code libraries, though updateable ones.

5.  Documentation sections were added or updated to help better 
explain the meaning of the in-DBMS entity namespaces, and various 
connected concepts.

See the "Changes" file ( 
http://search.cpan.org/src/DUNCAND/Language-MuldisD-0.11.0/Changes ) 
for more details of what changed for this release.

Separately, a small update 0.5.0 to Muldis::DB was released:


Its main change relates to DBMS objects now taking an extra setup 
parameter where users specify what query language they want to use 
with it, eg specifically what version of Muldis D, so that the Muldis 
DB implementation can unambiguously interpret the input it was given 
while supporting older or alternate language versions than the latest.

This feature is somewhat analagous to when you put a line at the top 
of Perl programs or modules that specifies what versions and/or 
minimal version of the Perl language it conforms to.

Its changes file has details.

The Muldis DB implementation is still not executing yet, sorry.

Thank you. -- Darren Duncan

More information about the Victoria-pm mailing list