Muldis::Rosetta Full-featured truly relational DBMS in Perl
Download

Muldis::Rosetta Ranking & Summary

Muldis::Rosetta Tags

Perl module perl relational DBMS relational DBMS

Muldis::Rosetta Description

Full-featured truly relational DBMS in Perl Muldis::Rosetta - Full-featured truly relational DBMS in Perl.The Muldis Rosetta 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 "Rosetta" file provides a 10,000 mile view of the Muldis Rosetta framework as a whole, and the detail documentation for each component is included with that component. The distribution containing this "Rosetta" file is the Muldis Rosetta core distribution.Loosely speaking, the Muldis Rosetta 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 Rosetta to work with databases. Like the Perl DBI, Muldis Rosetta has separately distributable core/API, implementation, and extension distributions. Like an implementation ("driver") of the Perl DBI, an implementation ("engine") of Muldis Rosetta 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. Also like the Perl DBI, Muldis Rosetta does not strictly require that said commands are written in any particular programming language. Unlike the Perl DBI, which typically takes commands in various implementation-specific dialects of SQL that are mutually incompatible to a large degree, Muldis Rosetta typically takes commands in various dialects of Muldis D that are highly standardized across implementations and have little or no mutual incompatability. See the separate all-documentation distribution Muldis::D for the formal definition of the Muldis D language, which Muldis Rosetta also serves as the reference implementation of.The minimal core of the Muldis Rosetta framework, the one component that probably every program would use, is the Muldis::Rosetta::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 Rosetta implementations to do and which applications invoke, called the Muldis Rosetta Native Interface (or MRNI). 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 Rosetta Engine or Engine.Thanks largely to the use of Muldis D as its primary command language, MRNI 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 Rosetta framework, everything else of substance in the same distribution as the minimal core (and this "Rosetta" file), comprises 2 additional components. The first is Muldis::Rosetta::Engine::Example, a self-contained and pure-Perl reference implementation of Muldis Rosetta. The second is Muldis::Rosetta::Validator, a common comprehensive test suite for Muldis Rosetta implementations. Together, these components make it possible for the Muldis Rosetta core distribution to be completely testable on its own. It is therefore also feasible for an application to use the Muldis Rosetta 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 Rosetta, 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 Rosetta documentation will be focusing mainly on how Muldis Rosetta 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::Rosetta::Interface file which provides the glue between your Perl code and your Muldis D code; "Muldis::Rosetta::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::Rosetta::Interface::Machine object represents a single active Muldis Rosetta 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 Rosetta 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 Rosetta should be thread safe and/or savvy in the future, but for now it officially is not and you should not share Muldis Rosetta objects between multiple threads, nor have objects in separate threads try to access the same external resources.Muldis Rosetta 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 any statements about 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 Rosetta 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 Rosetta 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 Rosetta Engine has the complete freedom to implement the Muldis Rosetta DBMS and Muldis D however it likes; all Muldis Rosetta 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 Rosetta 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 Rosetta'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 Rosetta'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 Rosetta. Such documentation is currently absent.In the context of a Muldis Rosetta implementation over the Perl DBI, if one were to categorize Muldis Rosetta 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. Requirements: · Perl

Muldis::Rosetta Related Software