View on
Darren Duncan > Muldis-DB-0.4.0 > Muldis::DB::SeeAlso


Annotate this POD

View/Report Bugs


Muldis::DB::SeeAlso - External resources that you really ought to look at


This document is Muldis::DB::SeeAlso version 0.4.0.


This document is a central location within the Muldis::DB distribution where any important recommendations of or links to external resources go. This includes both resources that were helpful in making Muldis DB, as well as resources that are or could be related to Muldis DB.


Please see the separately distributed Language::MuldisD distribution, which defines the Muldis D language that Muldis DB implements and uses as its primary API. Likewise see also the Language::MuldisD::SeeAlso appendix document of the Muldis D spec for links to various things comprising and related to The Third Manifesto, which Muldis DB is a formal implementation of by way of Muldis D.


This documentation is pending.



These are some theoretical examples of other Perl modules or documentation that could be created to work with Muldis DB, but if so would most likely be distributed independently from it. The given package names are examples, and the examples in question could have other names if appropriate.


Pod files with a potentially large collection of examples, tutorials, FAQs, and so on that help people learn how to employ Muldis DB for the things they need to do. In particular, there should be a lot of help given for people migrating from other systems that use different paradigms than Muldis DB does, for example SQL-using systems.

The Cookbook distro may also be the main repository of executing code that would otherwise go in the /examples directory of the Muldis DB core distro.

Genezzo or Genezzo::Muldis::DB or Muldis::DB::Engine::Genezzo etc

A Muldis DB Engine built around Jeffrey Cohen's Genezzo DBMS, or specifically the root module that provides the new_dbms function, could conceivably have either of the above file or package names, depending on what its author prefers, or something else yet. A strong name influence could be whether Muldis DB forms the sole public interface for Genezzo after its conversion to use it, or whether Genezzo would retain alternate public APIs that work without Muldis DB being present on the system. If Muldis DB is Genezzo's sole or primary interface, then simply Genezzo is probably best for branding.


Utility modules that take Perl Hosted Muldis D code as input and derive other PHMD code as output, such as with the purpose of refactoring them into canonical representations (such that manual code debugging or comparisons may be made easier), or forms that are more efficient for particular uses but are still logically equivalent.

Presumably all of these would work using static analysis methods and not actually "execute" anything, so they are independent of any particular Engine environment. This isn't to say that we can't separately have modules that help implement a specific Engine and do PHMD optimization that knows the specific needs of that Engine's implementation environment.

Other words that could go in such module names are like Optimize or Canon, or whatever authors prefer.

Muldis::DB::PHMD::YAML and Muldis::DB::PHMD::XML etc

Utility modules that serialize Perl Hosted Muldis D to, or unserialize it from, logically equivalent YAML, XML, or other generic data interchange formats. This implementation should be native to the Muldis D language itself and not output any Perl-specific details that aren't in non-Perl languages, so that it is suitable for interchange, at the very least between Perl 5 and Perl 6.


Utility module that parses Concrete Muldis D (character strings) into Perl Hosted Muldis D (tree of Perl Arrays etc), and also that generates the former from the latter. The 2 formats should basically have a 1:1 correspondence.


Implementation of a command-line user application over the Muldis DB API that takes Concrete Muldis D as input, compiles it and runs it, and nicely formats output for user display. This is analogous to DBI::Shell.


A wrapper over the Muldis DB API that makes it work as a DBI driver module, should that be useful. Depending on what DBI itself permits or requires, this could take a variety of query definition formats, including either or both of Concrete Muldis D or (most likely) Perl Hosted Muldis D.

Muldis::DB::PHMD::Translate::TutorialD etc

Utility module that parses the Tutorial D language into Perl Hosted Muldis D code, and also that generates the former from the latter. Mainly this is just by-the-book using the grammar published by Darwen and Date, but it could also handle compatible extensions by other D language implementations. In addition, separate utility modules can be made which translate to and from other D languages that don't look like Tutorial D.


Utility module that parses a Muldis DB-native variant of SQL into Perl Hosted Muldis D, and also that generates the former from the latter. This SQL variant is essentially a cleaned up subset of the SQL:2003 standard, with some misfeatures removed, some missing features added, and some alterations common in other SQL DBMSs substituted or added. Or alternately, it is like a subset of Muldis D made to look as much like SQL as possible. This Muldis DB-native SQL variant always has distinct column names in rowsets, requires matching column names for inputs to union/intersect/etc, never stores or results in duplicate rows, always uses 2-valued logic (not (>=3)-valued logic), and has case-sensitive table/column/etc names and character strings. An application written to use this SQL dialect rather than some other dialect should behave more deterministically, and perform faster, than ones written to some other SQL dialect, since there is less indirection involved between what users query and what actually happens to implement it.


Utility modules that parse other variants of SQL (or subsets thereof) into Perl Hosted Muldis D, and also that generate the former from the latter. Examples of these variants are the actual SQL:2003 standard, and the native dialects of each actual SQL DBMS.


Utility modules that translate data (including code and declaratives) between representations that are Perl Hosted Muldis D and representations that aren't, or between 2 of the latter kind while using the former kind as an intermediate representation. Besides the aforementioned possibilities that deal with D languages or SQL, we can have utilities that translate to/from native Perl data structures, including native Perl routine definitions (PPI would probably be employed in the Perl 5 version), and including commonly used third party class' objects.


Implementation(s) of a generic proxy server plus client for the Muldis DB API, letting the normal Muldis DB Engine and the user application reside in separate processes. The client would do Muldis::DB::Interface roles and the server would be an application or server-extending plugin that sits on top of the Muldis DB API. Or whatever implementers want to do. This is analogous to proxying modules for DBI or other DBMSs.


A default (but not mandatory) namespace for Muldis DB Engines to go, that provide the new_dbms function and do the Muldis::DB::Interface::\w+ roles. A lot of these would likely be implemented over existing DBMSs, which results in Muldis DB being an alternative API for them.

DBIx::Class::Storage::MuldisDB etc

An alternative plug-in storage engine for DBIx::Class that uses Muldis DB rather than DBI. Analogous extensions can be added to other DBI wrappers modules such as Tangram or Rose::DB or what have you. In either case, said alternatives can either be bundled with the core distros of those other modules, or separately from them, as per their authors' preferences.


Emulations of other modules or APIs as wrappers over Muldis DB. This is potentially the easiest way, short of the other modules themselves being appropriately updated, to permit migration for legacy apps to Muldis DB while they have the fewest actual code changes. The emulators would likely employ SQL translator utilities internally.


Unofficial extensions to Muldis DB could be named in this space, though it doesn't have to be used if prior coordination happens between developers.


This documentation is pending.

These Perl 5 applications and frameworks are, perhaps, at the front of the line to get Muldis DB bindings: Jifty, Catalyst, Maypole, Bricolage, RT. Generally speaking, the more active the development or the more popular the project, the higher the priority to support it.


This documentation is pending.

These other Perl 6 packages also work in the problem domain of managing data or data definitions or connections to databases:

Set::Relation, Set.

These other Perl 5 packages also work in the problem domain of managing data or data definitions or connections to databases (list not exhaustive):

DBI, Tangram, DBIx::Class, HDB, Class::DBI, Pixie, Alzabo, DBIx::SQLEngine, Rose::DB, SPOPS, Set::Object, Set::Scalar, Object::Relation, Oryx, DBM::Deep, DBIx::SearchBuilder, DBIx::RecordSet, DBIx::Abstract, DBIx::AnyDBD, DBIx::Browse, DBIx::DBH, MKDoc::SQL, Data::Transactional, DBIx::ModelUpdate, DBIx::ProcedureCall, DB::Ent, DBIx::Romani, DBIx::DBSchema, DBIx::Namespace, TripleStore, Data::Table, ORM, OOPS, Object::Transaction, Relations, DBIx::SimplePerl, DBIx::YAWM, Class::Entity, SQL::Statement, SQL::Parser, SQL::Translator, SQL::YASP, SQL::Generator, SQL::Schema, SQL::Abstract, SQL::Snippet, SQL::Catalog, DBIx::Perlish, Tao::DBI, NTuples, DBIx::CopyRecord.


Darren Duncan (


This file is part of the Muldis DB framework.

Muldis DB is Copyright © 2002-2007, Darren Duncan.

See the LICENSE AND COPYRIGHT of Muldis::DB for details.


The ACKNOWLEDGEMENTS in Muldis::DB apply to this file too.

syntax highlighting: