NAME
Muldis::DB::SeeAlso - External resources that you really ought to look at
VERSION
This document is Muldis::DB::SeeAlso version 0.3.0.
DESCRIPTION
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.
FORMAL SPECIFICATION
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.
LIST OF PUBLIC Muldis::DB ENGINES
This documentation is pending.
PROSPECTIVE Muldis::DB EXTENSIONS
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.
Muldis::DB::Cookbook(|::\w+)
-
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
orGenezzo::Muldis::DB
orMuldis::DB::Engine::Genezzo
etc-
A Muldis::DB Engine built around Jeffrey Cohen's Genezzo DBMS, or specifically the class that does
Muldis::DB::Engine::Role
, 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 simplyGenezzo
is probably best for branding. Muldis::DB::Literal::Refactor(|::\w+)
-
Utility modules that take Muldis::DB AST node objects as input and derive other nodes as output, such as with the purpose of refactoring them into canonical representations (such that users can then perform node value equality tests for potentially any type of node), 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 AST optimization that knows the specific needs of that Engine's implementation environment.
Other words that could go in such module names are like
Optimize
orCanon
, or whatever authors prefer. Muldis::DB::Literal::YAML
andMuldis::DB::Literal::XML
etc-
Utility modules that serialize Muldis::DB AST nodes to, or unserialize them 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.
Muldis::DB::Shell
-
Implementation of a command-line user application over the Muldis::DB API that takes string-form Muldis D as input, compiles it and runs it, and nicely formats output for user display. This is analogous to DBI::Shell.
DBD::Muldis::DB
-
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 AST form or string form (most likely) Muldis D.
Muldis::DB::Literal::Translate::TutorialD
etc-
Utility module that parses the Tutorial D language into Muldis::DB AST nodes, 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.
Muldis::DB::Literal::Translate::SQL::Native
-
Utility module that parses a Muldis::DB-native variant of SQL into Muldis::DB AST nodes, 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.
Muldis::DB::Literal::Translate::SQL::\w+
-
Utility modules that parse other variants of SQL (or subsets thereof) into Muldis::DB AST nodes, 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.
Muldis::DB::Literal::Translate::\w+
-
Utility modules that translate data (including code and declaratives) between representations that are Muldis::DB AST nodes 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.
Muldis::DB::Proxy::(Server|Client|\w+)
-
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 module would do
Muldis::DB::Engine::Role
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. Muldis::DB::Engine::(SQLite|Postgres|Oracle|\w+)
-
A default (but not mandatory) namespace for Muldis::DB Engines to go, that do
Muldis::DB::Engine::Role(|::\w+)
. 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::Muldis::DB
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.
Muldis::DB::Emulator::(DBI|JDBC|OCI|\w+)
-
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.
Muldis::DBx::\w+
-
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.
PUBLIC SOLUTIONS BUILT OVER Muldis::DB
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.
DBMS-RELATED PERL MODULES
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:
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.
AUTHOR
Darren Duncan (perl@DarrenDuncan.net
)
LICENSE AND COPYRIGHT
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.
ACKNOWLEDGEMENTS
The ACKNOWLEDGEMENTS in Muldis::DB apply to this file too.