NAME

Muldis::DB - Full-featured truly relational DBMS in Perl

VERSION

This document is Muldis::DB version 0.6.2.

DESCRIPTION

The Muldis DB DBMS framework is a powerful but elegant system, which makes it easy to create and use relational databases in a very reliable, portable, and efficient way. This "DB" file provides a 10,000 mile view of the Muldis DB framework as a whole, and the detail documentation for each component is included with that component. The distribution containing this "DB" file is the Muldis DB core distribution.

Loosely speaking, the Muldis DB framework at large is like the Perl DBI framework at large, so if you know how to use the Perl DBI to work with databases, it should be easy enough to apply that knowledge to using Muldis DB to work with databases. Like the Perl DBI, Muldis DB has separately distributable core, implementation, and extension distributions. Like an implementation ("driver") of the Perl DBI, an implementation ("engine") of Muldis DB works according to the command design pattern; its API is very minimalistic and mainly serves to process arbitrary "commands" through a single routine or three. Unlike the Perl DBI, which takes commands in some dialect of SQL, which changes based on the implementation in use, Muldis DB takes commands in the Muldis D language, which has just one dialect shared by all implementations. See the separate all-documentation distribution Muldis::D for the formal definition of the Muldis D language which Muldis DB is based on.

The minimal core of the Muldis DB framework, the one component that probably every program would use, is the Muldis::DB::Interface file. It defines a small set of roles/classes that comprise a common API (that processes Perl Hosted Data Muldis D commands) for Muldis DB implementations to do and which applications invoke, called the Muldis DB Native Interface (or MDBNI). For the most part, Interface just defines shims and it can only be used when they are subclassed by an implementation. In the Perl DBI framework analogy, Interface corresponds to the DBI module itself. An implementation is called a Muldis DB Engine or Engine.

Thanks largely to the use of Muldis D as its command language, MDBNI is rigorously defined, such that there should be no ambiguity when trying to invoke or implement it, and so an application written to it should behave identically no matter which conforming Engine is in use.

The maximal core of the Muldis DB framework, everything else of substance in the same distribution as the minimal core (and this "DB" file), comprises 2 additional components. The first is Muldis::DB::Engine::Example, a self-contained and pure-Perl reference implementation of Muldis DB. The second is Muldis::DB::Validator, a common comprehensive test suite for Muldis DB implementations. Together, these components make it possible for the Muldis DB core distribution to be completely testable on its own. It is therefore also feasible for an application to use the Muldis DB core in isolation from further framework components, though doing so isn't recommended for production use since Example is kept simple on purpose and doesn't scale well.

Muldis DB, by way of using the Muldis D language, incorporates a complete and uncompromising implementation of "The Third Manifesto" (TTM), a formal proposal by Christopher J. Date and Hugh Darwen for a solid foundation for data and database management systems (DBMSs); like Edgar F. Codd's original papers, TTM can be seen as an abstract blueprint for the design of a DBMS and the language interface to such a DBMS. Muldis D is a high-level programming language which is computationally complete (and industrial strength) and has fully integrated database functionality; it satisfies TTM's definition of a "D" language. The main web site for TTM is http://www.thethirdmanifesto.com/, and its authors have also written several books and papers and taught classes on the subject over the last 35+ years, along with Codd himself (some are listed in the separately distributed Muldis::D::SeeAlso documentation file). Note that the Muldis DB documentation will be focusing mainly on how Muldis DB itself works, and will not spend much time in providing rationale; you can read TTM itself and various other external documentation for much of that.

This documentation is pending.

While it is possible that one could write a self-contained application in Muldis D and compile that into its own executable, in practice one would normally just write some components of their application in Muldis D (as either named modules or anonymous routines) and write the rest of the application in their other language(s) of choice. Assuming the main application is written in Perl, it is the Muldis::DB::Interface file which provides the glue between your Perl code and your Muldis D code; "Muldis::DB::Interface" implements a virtual machine that is embedded in your Perl application and in which the Muldis D code runs (it is analogous to the Perl interpreter itself, which provides a virtual machine in which Perl code runs).

A Muldis::DB::Interface::Machine object represents a single active Muldis DB virtual machine; it has a spartan DBI-inspired set of methods which you use to compile/prepare and/or invoke/execute Muldis D statements and routines within the virtual machine, input data to it, and output data from it.

You can create more than one Machine object at a time, and they are essentially all isolated from each other, even if more than one uses the same Engine class to implement it; that is, multiple Machine objects will not have references to each other at a level visible in the Muldis DB Native Interface, if at all. To account for situations where multiple Machine objects want to use the same external resources, such as a repository file on disk, it is expected that the Engines will employ appropriate measures such as system-managed locks so that resource corruption or application failure is prevented. Also, Muldis DB should be thread safe and/or savvy in the future, but for now it officially is not and you should not share Muldis DB objects between multiple threads, nor have objects in separate threads try to access the same external resources.

Muldis DB does not use any dialect of SQL in its native API (unlike many other DBMS products) because SQL is more ambiguous and error-prone to use, and it is less expressive. While Muldis D is very different from SQL, it is fully capable of modeling anything in the real world accurately, and it can support a complete SQL emulation layer on top of it, so that your legacy applications can be migrated to use the Muldis DB DBMS with little trouble. Likewise, emulation layers for any other programming language can be supported, such as Tutorial D or XQuery or FoxPro or dBase.

One distinctive feature of a Muldis DB DBMS (compared to a typical other vendor's DBMS) is that data definition statements are structured fundamentally as standard data manipulation statements but that the target relation variables are system catalog relation variables rather than user-defined relation variables. In SQL terms, you create or alter tables by adding or updating their "information schema" records, which in SQL are read-only, not only by using special 'create' or 'alter' statements.

Each Muldis DB Engine has the complete freedom to implement the Muldis DB DBMS and Muldis D however it likes; all Muldis DB cares about is that the user interface and behaviour conform to its preconceptions.

For production use, there should be a wide variety of third party Engine modules that become available over time. One plan being favored is that the new (under development) enterprise-strength and Perl implemented database server named Genezzo (see also http://www.genezzo.com/) will evolve to implement the Muldis DB DBMS natively, and be the back-end which is recommended above all others for production use.

Most of the other (near term) third party Engines will likely just map Muldis DB's rigorously defined API onto a pre-existing quasi-relational database manager (such as SQLite, PostgreSQL, MySQL, Firebird, Teradata, Oracle, Sybase, SQL Server, Informix, DB2, OpenBase, FrontBase, etc). Given this fact, Muldis DB's most prominent feature is that it provides a common API for access to those databases, each of which takes a different SQL or quasi-SQL dialect. An application written to it should easily port to alternative relational database engines with minimal effort.

This might seem strange to somebody who has not tried to port between databases before, especially given that the Perl DBI purports to provide "Database Independence". However, the level of DBI's provided independence is Database Driver Independence, and not Database Language Independence. To further demonstrate the difference, it is useful to compare the DBI and Muldis DB. Such documentation is currently absent.

In the context of a Muldis DB implementation over the Perl DBI, if one were to categorize Muldis DB among other Perl modules, it could reasonably be called a database abstraction layer; but it should not be called a Perl object persistence layer, as that is a different paradigm.

FEATURE SUPPORT VALIDATION

The Muldis DB Native Interface declares accessors for a large number of actual or possible database features, any of which your application can invoke, and all of which each Muldis DB Engine would ideally implement or interface to.

In reality, however, all Engines or underlying databases probably don't support some features, and if your application tries to invoke any of the same features that an Engine you are using doesn't support, then you will have problems ranging from immediate crashes/exceptions to subtle data corruption over time.

As an official quality assurance (QA) measure, Muldis DB provides a means for each Engine to programmatically declare which features it does and does not support, so that code using that Engine will know so in advance of trying to use said features. Feature support declarations are typically coarse grained and lump closely similar things together, for simplicity; they will be just as fine grained as necessary and no finer (this can be changed over time). See the features() method, which is how you read the declarations.

One benefit of this QA feature is that, after you have written your application and it is working with one Engine/database, and you want to move it to a different Engine/database, you can determine at a glance which alternatives also support the features you are using. Note that, generally speaking, you would have to be using very proprietary features to begin with in order for the majority of Muldis DB Engines/databases to not support the application outright.

Another benefit of this QA feature is that there can be made a common comprehensive test suite to run against all Engines in order to tell that they are implementing the Muldis DB interface properly or not; said test suite will be smart enough to only test each Engine's compliance for those features that the Engine claims to support, and not fail it for non-working features that it explicitly says it doesn't support. This common test suite will save each Engine maker from having to write their own module tests. It would be used similarly to how Sun has an official validation suite for Java Virtual Machines to make sure they implement the official Java specification. Please see the Muldis::DB::Validator module(s), which implements this test suite.

SEE ALSO

The separate all-documentation distribution Muldis::D is the formal definition of the Muldis D language which Muldis DB is based on.

The Perl module Muldis::DB::Validator is bundled with Muldis DB and can be used to test Muldis DB Engines.

The Perl module Muldis::DB::Engine::Example is bundled with Muldis DB and implements a self-contained reference implementation of a Muldis DB Engine.

Go to the Muldis::DB::SeeAlso file for the majority of external references.

AUTHOR

Darren Duncan (perl@DarrenDuncan.net)

LICENSE AND COPYRIGHT

This file is part of the Muldis DB framework.

Muldis DB is Copyright © 2002-2008, Darren Duncan. All rights reserved.

Muldis DB is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License (LGPL) as published by the Free Software Foundation (http://www.fsf.org/); either version 3 of the License, or (at your option) any later version. You should have received a copy of the LGPL as part of the Muldis DB distribution, in the files named "LICENSE/LGPL" and "LICENSE/GPL" (the LGPLv3 is defined as the terms of the GPLv3 plus extra permissions); if not, see http://www.gnu.org/licenses/.

If it is not feasible for you to employ Muldis DB subject to the terms of the LGPL, then the copyright holder of Muldis DB can provide you a customized proprietary license, often at no cost, so that it is still possible for you to employ Muldis DB to meet your needs.

Any versions of Muldis DB that you modify and distribute must carry prominent notices stating that you changed the files and the date of any changes, in addition to preserving this original copyright notice and other credits. Muldis DB is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. However, for an additional fee, the copyright holders of Muldis DB can sell you a warranty for it.

While it is by no means required, the copyright holder of Muldis DB would appreciate being informed any time you create a modified version of Muldis DB that you are willing to distribute, because that is a practical way of suggesting improvements to the standard version.

TRADEMARK POLICY

The word MULDIS (in any letter case or font) is a Trademark (™), with Canadian registration pending (®), of Muldis Data Systems Inc. (http://www.muldis.com/), which is wholly owned by Darren Duncan. The trademark applies to computer database software and related services.

The word MULDIS was invented as a new word, through contraction of the quasi-meaningful phrase MULTIVERSE OF DISCOURSE, by Darren Duncan for the express purpose of using that word as a distinguishing brand name for the products and services (and entity name) of Muldis Data Systems. Said products and services are created for the world's betterment by way of the improved means to organize and share trustworthy data that their use enables. Muldis Data Systems is obligated to protect the reputation and identity of its name and works, which should be evoked by the MULDIS brand.

The trademark on MULDIS gives Muldis Data Systems the exclusive right to use the term to promote websites, businesses, products and services (such as the Muldis D language and Muldis DB software); however, we (Muldis Data Systems) are happy to give you permission to use the term under many circumstances without the need of any specific permission from us (in addition to what vanilla trademark law allows).

The following is a general policy that tells you when you can refer to the word MULDIS without need of any specific permission from us:

1. You must make clear that you are not Muldis Data Systems and that you do not represent Muldis Data Systems. A simple or conspicuous disclaimer on your home page and product or service documentation is an excellent way of doing that.

2. You may not incorporate the word MULDIS into the name or logo of your website, business, product or service; but see points 4 thru 6 for limited exceptions to this.

3. You may use the word MULDIS only in descriptions of your website, business, product or service to provide accurate information to the public about yourself.

4. If you have made a language variant or extension based on the Muldis D (Muldis::D) language, then the fully qualified machine readable name of your work may, and in fact should, use the base name Muldis_D as per the provisions of the VERSIONING documentation of the official Muldis D language spec.

5. The Perl package primary namespace Muldis:: is reserved for the official works of Muldis Data Systems (or works of third parties having explicit permission to use it). If you have made a variant or extension of any Muldis Data Systems work in Perl (such as Muldis DB; Muldis::DB), you may use the MuldisX:: namespace for it as per CPAN conventions, or alternately just use your own distinct brand. The same considerations apply to any secondary or tertiary (etc) namespaces where their ancestor namespaces serve as generic categorizing terms, such as Language:: or Data:: or Net::. For works you make in other programming languages than Perl, you should apply that language's or community's conventional naming practices for distinguishing official works from non-official ones.

6. If you have made a work or service that interacts with a Muldis Data Systems work or service for any reason, you may use the word MULDIS within the names of the components of your work or service that are involved in said interaction, as long as it is apparent by normal conventions that the word MULDIS is subservient to other parts of the name, such as your own main project name, and that the component is expressly a part of your work; for example, Foo::Storage::Muldis_DB or Bar::Interface::Muldis_DB.

If you would like to use the word MULDIS for any other use, please contact Muldis Data Systems and we'll discuss a way to make that happen. Assuming that you agree that our rights to the MULDIS trademark are valid and superior to yours, and that you take appropriate steps to ensure that people don't confuse you with us, then we should be able to make things work out. If you've already started using the word MULDIS in a way that would require permission, don't panic, but please contact us.

ACKNOWLEDGEMENTS

None yet.

FORUMS

Several public email-based forums exist whose main topic is all implementations of the Muldis D language, especially the Muldis DB project, which they are named for. All of these you can reach via http://mm.DarrenDuncan.net/mailman/listinfo; go there to manage your subscriptions to, or view the archives of, the following:

muldis-db-announce@mm.DarrenDuncan.net

This low-volume list is mainly for official announcements from the Muldis DB developers, though developers of Muldis DB extensions can also post their announcements here. This is not a discussion list.

muldis-db-users@mm.DarrenDuncan.net

This list is for general discussion among people who are using Muldis DB, which is not concerned with the implementation of Muldis DB itself. This is the best place to ask for basic help in getting Muldis DB installed on your machine or to make it do what you want. You could also submit feature requests or report perceived bugs here, if you don't want to use CPAN's RT system.

muldis-db-devel@mm.DarrenDuncan.net

This list is for discussion among people who are designing or implementing the Muldis DB core API (including Muldis D language design), or who are implementing Muldis DB Engines, or who are writing core documentation, tests, or examples. It is not the place for non-implementers to get help in using said.

An official IRC channel for Muldis DB is also intended, but not yet started.

Alternately, you can purchase more advanced commercial support for various Muldis D implementations, particularly Muldis DB, from its author by way of Muldis Data Systems; see (http://www.muldis.com/) for details.

cpanm Muldis::DB

perl -MCPAN -e shell
install Muldis::DB