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)