[socal-piggies] Django vs. TG

[Steve Wedig]

Interesting comparison that was sent out toe the django user list...

---------- Forwarded message ----------
From: tchoukharev at mail.ru <tchoukharev at mail.ru>
Date: Nov 28, 2006 1:21 PM
Subject: Why not Django
To: Django users <django-users at googlegroups.com>



I appologize for rather provocative subject line. I just want to tell
all why I could not use Django and had to use TurboGears
instead, even though I like Django more. I wrote this memo
for internal use, and then desided to post it inhere.

I have been involved in an initial development of database with a
web front-end. The original prototype of the system was written
practically in pure Python. We decided to start the new project
from evaluation of available development kits like Django and
TurboGears (all other candidates were rejected at very early
stage and will not be mentioned).

I'm going to share here the reasons why now we have decided to
go with TurboGears and not with Django.

The project we are doing is dealing with results of experimental
research work. It should store and manipulate great variety of
numerical data including but not limited to real and complex
scalar values, one-, two-, and many-dimensional arrays, and
other structured information. The plan is to build the core part
so that addition of one more type of data will be as simple as
possible.

Basing on this goal and previous experience, the priorities in
evaluation were set as follows. (First mark is for Django, second
for TurboGears; '-' means lack of the feature or worse than
avarage, '+' - the feature is available or better than avarage,
'0' - at avarage level.)

1. ACID compliance. Most important.                               ++
2. Inheritance for tables in DB. Most important.                  -+
3. Arrays of integers and floats. Very important.                 --
4. In case of arrays absence - binary data. Important.            --
5. Numeric data. Important.                                       -+
6. Potential for generic templates. Important.                    ++
7. Ready set of parameters for data and rendering defaults.       00
 Important.
8. Good error diagnostic messages. Important.                     +0
9. Documentation. Important.                                      +0
10. Overall consistency. Less important.                          +-
11. Good examples and discussion lists/forums.                    00
Less important.
12. Installation. Least important.                                ++

The importance marks are not for general use, just for this
particular project. For our next project they might change.

Now lets go over the list step by step.

1. ACID compliance. Here I mean not only atomicity,
consistency, isolation, durability of every change made by
the program to DB. The system should also check, that the
data were not changed between retrieving the information by
the client and the beginning of the changing operation after
the client's reply.Given the stateless nature of http, I see only
one good approach to it. The information obtained from DB for
update, is sent to the client in two separate pieces, as a form
for corrections, and as a set of hidden fields. When the client
clicks on OK button, the program can start a transaction by
doing 'SELECT FOR UPDATE' with the original data from the
hidden fields, then update data and close the transaction.
Any error should lead to the transaction rollback.
I did not find anything like that neither in Django nor in
TurboGears.
On the other hand, a bit less reliable optimistic approach can
be easily implemented both in Django and TurboGears. An
additional field with timestamp of last change is added to
each table and this value is used to verify that data were not
changed before updating.
As to other parts of ACID compliance, both competitors do
good job and differ only in details of implementation. Draw.

2. Inheritance for tables in DB. Structure of the information in
the project allows to organize it in a set of tables related by
inheritance. PostgreSQL has this inheritance in declaration of
tables. Similar inheritance is implemented in TurboGears (both
in SQLObject and SQLAlchemy). Django also has inheritance
in the class declaration corresponding to the tables, but use
of it leads to creation of separate, unconnected tables, so that
the derived table has all columns of the parent table plus
columns declared in the derived class itself. What can be
used in Django to build similar structure is OneToOneField.
But the implementation of the manipulators lies on the
programmer. A minor complication is the name of
OneToOneField. It should be not id (as all other primary key
columns are) but parent_id, where parent is the name of the
related table. Probably, this is forced by some reasons for
other usages of the field, but in simulating inheritance in the
desired sense this needs special care.
This point is definitely won by TurboGears.

3. Arrays of integers and floats. PostgreSQL allows to use
arrays of numerical data as column types. This is very helpful
for storing regular numerical data. Neither TurboGears nor
Django implement these types.

4. Binary fields. These fields could be used to store structured
data in case of absence of numerical arrays and other
structured fields. Coupled with simple pack-unpack functions
they can serve reasonably well. Neither TurboGears nor Django
implement these types. Django has FileField, which stores data
in external files, not managed by the DBMS, this is not what is
needed. Also, there is a patch adding binary fields to Django,
but it is not yet included into any released version. Thus, both
TurboGears and Django force us to use string fields with pack/
unpack operations. Draw.

5. Numeric data. Frankly speaking, we did not expect any
problems for this point. Surprisingly, Django FloatField is not
a float at all, it's numeric, i.e. fixed decimal point type! This
makes it much more difficult to store simple physical constants,
e.g. Planck constant, speed of light, etc. Why isn't it called
NumericField or FixedField?! Won by TurboGears.

6. Potential for generic templates. Both TurboGears and Django
offer reasonable template language by default, and both allow to
use any other templating system. Draw.

7. Ready set of parameters for data defaults and rendering. Both
TurboGears and Django give some number of the important
parameters. I will only mention the parameters I expected to
see and did not find. For IPAdressField I thought the most
obvious default value would be IP of the client's computer
(or last resolvable proxy, for that matters). For CharField I
wanted username and FQDN of the client's computer. (These
might be separate field types, of course, like ClientIPField,
UsernameField etc.) Neither TurboGears nor Django implement
these defaults. TurboGears seemingly has some problems with
selecting the choices for a SingleSelectField (a widget used for
ForeignKey), the selection cannot be simply declared in the
table definition, since the tables are not yet created and evaluation
is not so 'lazy'. TurboGears and Django are very close, with my
sympathy on Django side.

8. Good error diagnostic messages. Django has perfect messages.
I did not see anything I would like to be added to them. Messages
of TurboGears are more obscure, reflecting the difference of design
in different parts of the system. Fortunately, result of print
statement in the development mode comes directly to the terminal
where the development server was started, giving the programmer
usual tool for debugging of the python scripts. Fixing wrong
templates is trickier. Django won.

9. Documentation. Definitely won by Django.

10. Overall consistency. Definitely won by Django.

11. Good examples and discussion lists/forums. TurboGears has
more users and more examples, but they are of wider range of
ability to help. Django has enough examples for usual cases and
the questions on their lists are well answered. Unfortunately, our
case is not so usual and the number of applicable examples is
close to zero for both systems. Draw.

12. Installation. No problem for both. Draw.

Thus, the absence (or different meaning) of table inheritance and
FloatField made the choice of TurboGears over Django for our
project.

Best regards,
V.Chukharev


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google
Groups "Django users" group.
To post to this group, send email to django-users at googlegroups.com
To unsubscribe from this group, send email to
django-users-unsubscribe at googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---