StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>Not trying to defend Django (that is not my job! :-)) just trying to give you some pointers on your list of limitations...</p> <blockquote> <p>as of december 2009 no model validation</p> </blockquote> <p>What exactly do you mean by this? Validation is available at the form level... And you can always override the <code>save()</code> method to implement whatever logic you desire and stop the save operation... Can you give an example of a scenario?</p> <blockquote> <p>the templating system is only good as far as you don't need custom template tags the idea to separate the design from the logic seemed good, it is frustrating, that I cannot sum 2 numbers in the view</p> </blockquote> <p><a href="http://docs.djangoproject.com/en/dev/ref/templates/builtins/#add" rel="noreferrer">Add two numbers?</a></p> <p>That said, you are not married to Django's templating system. You can use, for instance, <a href="http://lethain.com/entry/2008/jul/22/replacing-django-s-template-language-with-jinja2/" rel="noreferrer">Jinja2</a>.</p> <blockquote> <p>the template language is not designer friendly</p> </blockquote> <p>Uhhh... Why? Most designers I worked with had no problem working with template languages way more complex than Django's... Could you give an example of what you see as unfriendly? Maybe there is a work-around.</p> <blockquote> <p>the stack trace of an ex in a custom template tag is useless (if used with python 2.6). There is a patch for it, but it will go into django just in 1.2</p> </blockquote> <p>I haven't experienced this stack trace issue you discuss. You can always install the patch until Django 1.2 is around though. So it seems you have a solution available. </p> <blockquote> <p>django's orm (to connect to legacy systems) cannot handle blob fields</p> </blockquote> <p>If you are dealing with the need to store files in the database, maybe you should look at the <a href="http://code.welldev.org/django-storages/wiki/Home" rel="noreferrer">django-storages</a>' DatabaseStorage.</p> <blockquote> <p>cannot handle multi-column pk fields</p> </blockquote> <p>This, alongside with multiple database support, are the areas of real need of improvement - I agree. </p> <p>I suppose you could not use models (just straight SQL) for models that have the multi-column pk requirement (yes, it would kill the admin, but it is doable). Frankly - I don't have that problem in my models because I prefer surrogate primary keys - if a legacy model is on my way, I add a surrogate primary key to it - all the legacy code should continue to work and Django will be happy. But I do have complete control over the database tables, which might not be your case.</p> <p>Multi-column primary keys <a href="http://code.djangoproject.com/wiki/Version1.2Features" rel="noreferrer">are medium priority for the 1.2 release</a>.</p> <p>Multidb is <a href="http://code.djangoproject.com/wiki/Version1.2Features" rel="noreferrer">high priority for 1.2 release</a>.</p> <p>The 1.2 release is <a href="http://code.djangoproject.com/wiki/Version1.2Roadmap" rel="noreferrer">expected by March 2010</a>. Sure, the date is not written in stone. </p> <p>Given my experience with other frameworks, I would rather work around my issues and stick to Django.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload