logo
Free, unlimited AI code reviews that run on commit
git-lrc git-lrc GitHub Install Now We'd appreciate a star git-lrc - Free, unlimited AI code reviews that run on commit | Product Hunt git-lrc - Free, unlimited AI code reviews that run on commit | Product Hunt

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.

   DESIGNCAVEATSquerylanguagedoesnotcoverallSQLexpressions
           Whilst  there  is no underlying fault with the query object metaphor perse, 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.

       somelossofencapsulationwithqueries
           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 dataaccesspatterns, which the Tangram schema represents.  But OO  terms
           like that are usually treated as buzzwords anyway.

   HARDPROBLEMSpartialcolumnselect
           This optimisation has some serious dangers associated with it.

           It could either be

       nosupportforSQLUPDATE
           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)
                 );

       noexplicitsupportforre-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.

       replaceSQLexpressioncore
           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.

       supportfor`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 do this without loading  the  entire
           collection into memory.

           This could actually be achieved with a new Tangram::Type.

   MISSINGFEATURESconcisequeryexpressions
           For simple selects, the query syntax is too long.  Getting remote objects should take less code.

       non-IDjoins
           We can't join on anything but "ID" values

       tableswithnoprimarykey
           We  can't  map  tables  unless they have a primary key, and it is called "id" (or, at least, the same
           name as the rest of the schema).

       tableswithmulti-columnprimarykeys
           We can't map tables when they have multiple primary keys.  Well, you can, but only if you make a view
           with an ID column which is functionally derived from the multi-part keys.  But that sucks.

       tableswithauto_incrementkeys
           These suck, but Tangram could still support them without requiring schema hacks.

       tableswithouta`type'column
           The 'type' column is unneeded for base tables which do not have sub-classes.

       tableswithcustom`type'columns
           For mapping schemata where some clever person has invented their  own  special  way  of  representing
           types using discrete column values.

       tableswithimplicit(presence)`type'columns
           It  should be possible to infer the type value based on knowledge of the schema, and the tables which
           have rows.

       fullysymmetricrelationships
           back-refs are read-only.

       bulkinserts
           Inserting lots of similar objects should be more  efficient.   Right  now  it  generates  a  new  DBI
           statement handler for each object.

       `emptysubclass'schemasupport
           You  should  not need to explicitly add new classes to a schema if a superclass of them is already in
           the schema.

       warnaboutcolumnredefinitions
           Defining a column twice should be an error.  Reported by Mark Lawrence.

perl v5.36.0                                       2022-10-16                                Tangram::Sucks(3pm)

Name

       Tangram::Sucks - what there is to be improved in Tangram

See Also