trusty (3) Tangram::Sucks.3pm.gz

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 difficult 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 container, 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.