GSP
Quick Navigator

Search Site

Unix VPS
A - Starter
B - Basic
C - Preferred
D - Commercial
MPS - Dedicated
Previous VPSs
* Sign Up! *

Support
Contact Us
Online Help
Handbooks
Domain Status
Man Pages

FAQ
Virtual Servers
Pricing
Billing
Technical

Network
Facilities
Connectivity
Topology Map

Miscellaneous
Server Agreement
Year 2038
Credits
 

USA Flag

 

 

Man Pages


Manual Reference Pages  -  TANGRAM::SUCKS (3)

.ds Aq ’

NAME

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

CONTENTS

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

<B>query language does not cover all SQL expressionsB> 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.
<B>some loss of encapsulation with queriesB> 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

<B>partial column selectB> This optimisation has some serious dangers associated with it.

It could either be

<B>no support for SQL UPDATEB> 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)
      );



<B>no explicit support for re-orgsB> 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.

<B>replace SQL expression coreB> 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.
<B>support for ‘large’ collectionsB> 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.

    MISSING FEATURES

<B>concise query expressionsB> For simple selects, the query syntax is too long. Getting remote objects should take less code.
<B>non-ID joinsB> We can’t join on anything but ID values
<B>tables with no primary keyB> 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).
<B>tables with multi-column primary keysB> 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.
<B>tables with auto_increment keysB> These suck, but Tangram could still support them without requiring schema hacks.
<B>tables without a ‘type’ columnB> The ’type’ column is unneeded for base tables which do not have sub-classes.
<B>tables with custom ‘type’ columnsB> For mapping schemata where some clever person has invented their own special way of representing types using discrete column values.
<B>tables with implicit (presence) ‘type’ columnsB> It should be possible to infer the type value based on knowledge of the schema, and the tables which have rows.
<B>fully symmetric relationshipsB> back-refs are read-only.
<B>bulk insertsB> Inserting lots of similar objects should be more efficient. Right now it generates a new DBI statement handler for each object.
<B>‘empty subclass’ schema supportB> You should not need to explicitly add new classes to a schema if a superclass of them is already in the schema.
<B>warn about column redefinitionsB> Defining a column twice should be an error. Reported by Mark Lawrence.
Search for    or go to Top of page |  Section 3 |  Main Index


perl v5.20.3 TANGRAM::SUCKS (3) 2015-10-09

Powered by GSP Visit the GSP FreeBSD Man Page Interface.
Output converted with manServer 1.07.