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@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---