1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
|
PERFORMANCE & CACHING
=====================
* django doesn't do proper eager loading of several levels deep, so the sucky performance
can only be fixed by using a cache (or with roll-your-own SQL).
* To use a cache, the updated_at date of the parent object should be updated whenever a
child object is modified/added/deleted. This involves updating the top-level run for
example for every change in builds, results, bugs, etc.
* Then, to cache, one can simply send out a last_modified header (that will also enable
caching along the way)
DJANGO vs SINATRA + ACTIVERECORD
==============================
* Django doesn't support migrations (so troublesome to change the DB layout).
* Django insists on prefixing tables with the "application" name; needs to be overridden
once per model.
* Python as a whole doesn't support proper dependency tracking like Ruby does with
bundler and Gemfiles.
* Django doesn't do eager loading several levels deep, leading to way sub-optimal
performance. See http://validation.linaro.org/lava-server/dashboard/tests/cts/ for
example. Takes minutes to load - would take ms to load using ActiveRecord with eager
loading.
* Django serializers are extremely limited. Not customizable at all, don't take any
useful options. They also require "querysets" and can't serialize an object on
its own. That way even single serialized objects are serialized as a set/array - not
very clever.
* Django serializers have a very weird idea of how serialized data looks like; e.g.
what any normal framework would output as: { id: 1, name: 'Alex' }, Django outputs
as { pk: 1, model: 'foo.Person', fields: { name: 'Alex' } }. I mean, seriously? Who
wants that? Overwriting the behaviour requires writing bits of your own serializer.
* Ruby has way way more tools for web development. Tools meaning: tools, plugins, etc.
For example Rack (the http "stack") has a zillion different plugins, and is trivially
extensible.
Templates
===========
* Django templates are really really limited - you can't simply choose to use a different
templating language, you are really stuck with the sh** that ships with django.
* Not being able to do function calls, etc, is extremely limiting. Models end up having
a function and a property for that function, for example.
* To achieve anything halfway useful you have to write your own templating tags and
filters. Fact is that being able to put tiny bits of actual code (e.g. python code)
in the templates is extremely helpful and doesn't make it any worse.
|