1
2=head1 NAME
3
4Tangram::Sucks - what there is to be improved in Tangram
5
6=head1 DESCRIPTION
7
8Tangram has taken a concept very familiar to programmers in Java land
9to its logical completion.
10
11This document is an attempt by the coders of Tangram to summarise the
12major problems that are inherant in the design, describe cases for
13which the Tangram metaphor does not work well, and list long standing
14TO-DO items.
15
16=head2 DESIGN CAVEATS
17
18=over
19
20=item B<query language does not cover all SQL expressions>
21
22Whilst there is no underlying fault with the query object metaphor
23I<per se>, there are currently lots of queries that cannot be
24expressed in current versions of Tangram, and adding new parts to the
25language is not easy.
26
27=item B<some loss of encapsulation with queries>
28
29It could be said this is not a problem.  After all, adding properties
30to a schema of an object is akin to declaring them as "public".
31
32Some people banter on about I<data access patterns>, which the Tangram
33schema represents.  But OO terms like that are usually treated as
34buzzwords anyway.
35
36=back
37
38=head2 HARD PROBLEMS
39
40=over
41
42=item B<partial column select>
43
44This optimisation has some serious dangers associated with it.
45
46It could either be
47
48=item B<no support for SQL UPDATE>
49
50It may be possible to write a version of C<$storage-E<gt>select()>
51that does this, which would look something like:
52
53  $storage->update
54      ( $r_object,
55        set => [ $r_object->{bar} == $r_object->{baz} + 2 ],
56        filter => ($r_object->{frop} != undef)
57      );
58
59=item B<no explicit support for re-orgs>
60
61The situation where you have a large amount of schema reshaping to do,
62with a complex enough data structure can turn into a fairly difficult
63problem.
64
65It is possible to have two Tangram stores with different schema and
66simply load objects from one and put them in the other - however the
67on-demand autoloading combined with the automatic insertion of unknown
68objects will result in the entire database being loaded into core if
69it is sufficiently interlinked.
70
71=item B<replace SQL expression core>
72
73The whole SQL expression core needs to be replaced with a SQL
74abstraction module that is a little better planned.  For instance,
75there should be placeholders used in a lot more places where the code
76just sticks in an integer etc.
77
78=item B<support for `large' collections>
79
80Where it is impractical or undesirable to load all of a collection
81into memory, when you are adding a member and then updating the
82container, it should be possible to do this without loading the
83entire collection into memory.
84
85This could actually be achieved with a new Tangram::Type.
86
87=back
88
89=head2 MISSING FEATURES
90
91=over
92
93=item B<concise query expressions>
94
95For simple selects, the query syntax is too long.  Getting remote
96objects should take less code.
97
98=item B<non-ID joins>
99
100We can't join on anything but "ID" values
101
102=item B<tables with no primary key>
103
104We can't map tables unless they have a primary key, and it is called
105"id" (or, at least, the same name as the rest of the schema).
106
107=item B<tables with multi-column primary keys>
108
109We can't map tables when they have multiple primary keys.  Well, you
110can, but only if you make a view with an ID column which is
111functionally derived from the multi-part keys.  But that sucks.
112
113=item B<tables with auto_increment keys>
114
115These suck, but Tangram could still support them without requiring
116schema hacks.
117
118=item B<tables without a `type' column>
119
120The 'type' column is unneeded for base tables which do not have
121sub-classes.
122
123=item B<tables with custom `type' columns>
124
125For mapping schemata where some clever person has invented their own
126special way of representing types using discrete column values.
127
128=item B<tables with implicit (presence) `type' columns>
129
130It should be possible to infer the type value based on knowledge of
131the schema, and the tables which have rows.
132
133=item B<fully symmetric relationships>
134
135back-refs are read-only.
136
137=item B<bulk inserts>
138
139Inserting lots of similar objects should be more efficient.  Right now
140it generates a new DBI statement handler for each object.
141
142=item B<`empty subclass' schema support>
143
144You should not need to explicitly add new classes to a schema if a
145superclass of them is already in the schema.
146
147=item B<warn about column redefinitions>
148
149Defining a column twice should be an error.  Reported by Mark
150Lawrence.
151
152=back
153
154
155=cut
156
157