tangram::sucks(3pm) [debian man page]
Tangram::Sucks(3pm) User Contributed Perl Documentation Tangram::Sucks(3pm) NAME
Tangram::Sucks - what there is to be improved in Tangram DESCRIPTION
Tangram has taken a concept very familiar to programmers in Java land to its logical completion. This document is an attempt by the coders of Tangram to summarise the major problems that are inherant in the design, describe cases for which the Tangram metaphor does not work well, and list long standing TO-DO items. DESIGN CAVEATS query language does not cover all SQL expressions Whilst there is no underlying fault with the query object metaphor per se, there are currently lots of queries that cannot be expressed in current versions of Tangram, and adding new parts to the language is not easy. some loss of encapsulation with queries It could be said this is not a problem. After all, adding properties to a schema of an object is akin to declaring them as "public". Some people banter on about data access patterns, which the Tangram schema represents. But OO terms like that are usually treated as buzzwords anyway. HARD PROBLEMS partial column select This optimisation has some serious dangers associated with it. It could either be no support for SQL UPDATE It may be possible to write a version of "$storage->select()" that does this, which would look something like: $storage->update ( $r_object, set => [ $r_object->{bar} == $r_object->{baz} + 2 ], filter => ($r_object->{frop} != undef) ); no explicit support for re-orgs The situation where you have a large amount of schema reshaping to do, with a complex enough data structure can turn into a fairly dif- ficult problem. It is possible to have two Tangram stores with different schema and simply load objects from one and put them in the other - however the on-demand autoloading combined with the automatic insertion of unknown objects will result in the entire database being loaded into core if it is sufficiently interlinked. replace SQL expression core The whole SQL expression core needs to be replaced with a SQL abstraction module that is a little better planned. For instance, there should be placeholders used in a lot more places where the code just sticks in an integer etc. support for `large' collections Where it is impractical or undesirable to load all of a collection into memory, when you are adding a member and then updating the con- tainer, it should be possible to This could actually be achieved with a new Tangram::Type. MISSING FEATURES concise query expressions For simple selects, this is too long: ... non-ID joins tables with no primary key tables with multi-column primary keys tables with auto_increment keys tables without a `type' column tables with custom `type' columns tables with implicit (presence) `type' columns fully symmetric relationships back-refs are read-only. bulk inserts Inserting lots of similar objects should be more efficient. Right now it generates a new STH for each object. `empty subclass' schema support You should not need to explicitly add new classes to a schema if a superclass of them is already in the schema. perl v5.8.8 2006-03-29 Tangram::Sucks(3pm)
Check Out this Related Man Page
Tangram(3pm) User Contributed Perl Documentation Tangram(3pm) NAME
Tangram - Store pure objects in standard relational databases SYNOPSIS
See Tangram::Tour DESCRIPTION
Tangram is an object-relational mapper. It is orthogonal, meaning that it does not require anything of the objects stored in it (other than the common convention that base objects be based upon HASHes; individual columns can be anything). It consists of a schema language that can describe or be built around an object structure, or so as to closely match an existing SQL schema (with some limitations). This schema language is rich enough to express such common RDBMS features as links, foreign keys, and link tables. It also consists of a relational database storage engine, which based on the schema structure, will make Perl structures persist in a rela- tional (SQL compliant) database. References to other objects (or collections, as represented with foreign keys and link tables) may be loaded using on demand references that `lazily' load data when it is needed. As of Tangram 2.08, the schema need not describe every single object property, so that you can map only the columns you intend to query. The rest of the object is then stored in a column via a serialiser, like Data::Dumper, YAML or Storable. These structures themselves may contain arbitrary references to other objects in storage. Tangram has soundly engineered transaction support, without sacrificing excellent data caching abilities. The general optimisation strat- egy of the code makes it most suited for OLTP (aka application servers) and other situations where it is better to select and update whole rows than to worry about which columns to retrieve/update or not retrieve/update. Once your object are persistent, you can build query expressions to find them in terms of the schema language that you used to put them in. Therefore, the schema data structure does not describe a data structure, it describes a data access pattern. If you are not picky about which accessor module to use, preferring to specify the schema once only, then you can use the seperately dis- tributed Class::Tangram::Generator to make a set of classes from a Tangram schema structure. If you are looking for a tool that implements SQL abstraction only, you have probably missed the point (of this module, anyway), and a well-supported module like Class::DBI, or an interactive SQL modeller like Alzabo will likely suit your needs better. Tangram is beginning to include preliminary support for aggregation functions, and currently supports grouping, summing and counting. Joins must currently be in terms of integer primary key columns, to extend past this would require extra mapping types to be developed. Basic support for alternative join types is present, but in its infancy. Tangram currently contains no support for database-side updates (ie, "UPDATE foo SET bar = 'baz' where frop = 'blarg'"), but support is planned. There is no support for creating views based on existing classes to make new derived classes; you have to use your database SQL and create corresponding Tangram classes manually to do that. Tangram has a web site at <http://tangram.utsl.gen.nz/>, currently sponsored by MarketView (New Zealand) Ltd. DOCUMENTATION INDEX
CONTENTS
Tangram::Tour The original "Guided Tour" of the features of Tangram, by Jean-Louis LeRoy. Tangram::Intro The humble beginnings of a new guided tour, based on the next-generation features found in Tangram 2.08. Tangram::Springfield The classes and schema used in the Guided Tour(s). Tangram::Storage The main database handle class. Includes details on query syntax. Tangram::Cursor Return an iterator that retrieves persistent objects in a result set one by one. Tangram::Schema The Tangram schema structure - representing your data model so that Tangram can map it. Tangram::Relational::Mappings An informative text on exactly how Object Relational Mapping is accomplished by the Tangram::Relational back-end, what the different styles of mapping are, and how each is selected. Tangram::Type What Tangram types are available. This page is an index of other manual pages that express the data and relationship types available in Tangram. Tangram::Type::Extending How to write your own custom types for Tangram. Tangram::Dialect Database-specific extensions to Tangram, such as Tangram::mysql and Tangram::Sybase. These extensions only add functionality, and are not required for core operation of Tangram. COMPATIBILITY
Tangram has been known to run in the following environments, however, Tangram uses standard SQL and should be usable with any SQL-83 com- pliant database. Most of the requirements are simply avoiding the worst bugs. Note that some functions (e.g. transactions and subselects) may not be available in some environments. This is reported during the test suite. * Perl 5.005_03+, 5.6.1+, 5.8.1+ (5.8.0 had a nasty bug and doesn't work with Tangram) * Set::Object 1.04 (though the latest version is highly recommended) * DBI 1.14 * DBD::mysql 2.0402 * DBD::Oracle 1.06 * DBD::Sybase 0.21 * DBD::SQLite 1.07 * DBD::Pg 0.93 LICENSE &; WARRANTY You may use Tangram, free of charge, under the terms of the GPL. This notice applies to the entire distribution and all of its parts. You can obtain a commercial license for old (2.04 and earlier) versions of Tangram from Sound Object Logic, see http://www.soundobject- logic.com/tangram/licenses.html. TANGRAM COMES WITHOUT ANY WARRANTY OF ANY KIND. IT DOES NOT EVEN COME WITH ANY KIND OF VAGUE IMPLICATION THAT IT DOES ANYTHING MORE THAN GIVE YOUR COMPUTER HINTS ABOUT HOW TO TRY STIRRING ITS ELECTRONS. THE AUTHORS ARE NOT RESPONSIBLE FOR THE RESULTANT ELECTRON CONFIGURATION IN ANY WAY INCLUDING TRANSMUTATIONS OF ELECTRONS INTO OTHER FIELDS SUCH AS MAGNETIC MEDIA OR PUNCH CARDS. SUPPORT
Please send bug reports directly to the Tangram 2 maintainer's mailing list <t2-users@lists.utsl.gen.nz>, and please CC: <bug-Tan- gram@rt.cpan.org> so your fault can be tracked accurately. Whenever possible, include a short yet complete script demonstrating the problem. (read: if you want it fixed quicker, demonstrate it) Questions of general interest should should be posted to the mailing list, but not sent to rt.cpan.org. AUTHORS
All the code and documentation for versions 2.04 and earlier, as well as some changes in the 2.05 release, were written by Jean-Louis Leroy (jll@soundobjectlogic.com) and Sound Object Logic. Sam Vilain <sam@vilain.net> is the author of the derived work that is Tangram 2.05 and later. Andres Kievsky <ank@cpan.org> has contributed to the Tangram code starting with Tangram 2.08. perl v5.8.8 2006-03-29 Tangram(3pm)