All,
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:
http://search.cpan.org/dist/Language-MuldisD/
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
others.
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
does.
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:
http://search.cpan.org/dist/Muldis-DB/
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
_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/[EMAIL PROTECTED]
