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)