JeffCroft.com

07.20.2006 // 64 Comments // News Center Top ten things that suck about Django

By now, everyone knows I use and like Django a lot. But it’s not perfect. There are definitely things I think could be better, as well as things I think should exist that don’t. The good news, of course, is that Django is open source, so it wouldn’t be terribly hard for a talented programmer to create patches to take care of some of these issues. In fact, some are already being taken care of.

So, to prove I’m not such a Django fanboy that I can’t see fault in it, I give you my list of the Top Ten Things that Suck About Django. Feel free to add your own, and especially feel free to create patches to solve any of these issues!

  1. Painful schema migration. So you’ve got a basic Django blog running and it’s working well. You’ve been using it for weeks and have a good bit of data in your database. You decide you’d like to let your buddy write a post on your blog, but you didn’t design it to be multi-author. You now need a field on your Entry object with a ForeignKey to User. You add it to your model definition, but in order to get the column added to your database, you’ve either got to reset your blog application’s tables (i.e. delete all your data) or manually write and run the SQL needed to add the column. It’s pretty frustrating, especially if you hate SQL like I do. Good news is, there are at least a few in-progress attempts are correcting this, including a Google Summer of Code project.
  2. Admin interface/authentication module: inability for a user to edit only objects he/she has created. Django’s built in admin interface and authentication system doesn’t support permissions on a granular-enough level. If I have a model called “BlogEntry,” I’ll get (for free) permissions I can apply to each user, including “Can add Blog Entries,” “Can delete Blog Entries,” and “Can change Blog Entries.” What I can’t do, though, is say “this user can create new blog entries and edit the ones they have created — but no one else’s.”
  3. Admin interface: inability to delete multiple items at once. As kick-ass as the admin interface is, it does have one major oversight: there’s no fast way to delete many instances of the same object type. So, for example, when I have a list of comment objects and half of them are spam, I have to click each one and click the “delete” button on each comment’s detail page. I can’t simply select a checkbox next to each of the items and say “delete all.”
  4. Contrib apps: No django.contrib.search. The contrib apps that are bundled with Django basically try to cover common cases for you, making the things you do over and over again easier and faster. Some of them include a feed creation framework, a generic comments application, the admin interface, the auth/auth module, and more. The one thing that seems like an incredibly common case that isn’t covered is a search engine. Almost every site needs one — Django should provide one, in my opinion. I believe there is a Google Summer of Code project tackling this already, so hopefully we’ll see one soon.
  5. Install: Relatively painful process. Having never installed Rails or another web framework like Django, I can’t compare Django’s install with them. But, I do know that ever since I posted my Setting Up Django on Dreamhost tutorial, I’ve gotten a lot of e-mails from people hung up somewhere in the install process. It’s not so much that it’s hard — anyone with some basic Unix experience can handle it. It’s more that there are a lot of steps and a lot of failure points. Some kind of automated install script would be very, very welcome.
  6. General: The fact that the trunk branch and release version are so different. I understand the reason for this. Magic-removal was a huge, and much-needed, re-factoring that resulted in tons of improvements for the framework. The magic-removal branch was merged with trunk way back on May 1st, and all of the documentation on the official site was changed to reflect the new syntax (the old is still there, as well, for the archives). Just about everyone who knows Django will recommend you use the trunk branch with its new syntax. But, almost three months after the merge, the official “release” version of Django hasn’t changed. This isn’t so much a real-world usage problem — if you use the development version, you’ll be fine. But, I think it causes perception problems. People perceive Django as “unstable” or “in a state of flux” or “immature” because the documentation doesn’t apply to the downloadable, “official” release of the framework. This should be solved when .95 is released, but it seems like it’s been going on too long. I don’t know what the hold-up is on .95, but I believe the perception that Django’s syntax is still a moving target is keeping a lot of people from trying it — even though the vast majority of syntax changes have long since been completed.

And I’m spent. I can only come up with six. I’m sure there are others — probably things that don’t affect me with the way I usually use Django (mostly generic views). Help me fill out the last four, won’t you?

Comments

There are currently 64 comments on this entry. If you have something to say, please consider adding your own.

You can also subscribe to an RSS feed of this entry’s comments.

This entry’s tags

Comments

  1. 001 // Jacob Kaplan-Moss // 07.20.2006 // 11:44 AM

    Great list, Jeff. It’ll be intersting to see how mature our community is at taking critcism :)

    I’m pretty excited to see that three of your six items are being addressed as we speak ‘” that tells me we’re putting our energies in the right place.

    Here’s a #7: lack of an end-user testing framework. Tests are really important to application quality, and Django needs a way of doing them that lives up to the slickness of the rest of the framework. Luckily, again, this is something that’s being worked on right now; see #2333.

  2. 002 // James Bennett // 07.20.2006 // 11:46 AM

    It doesn’t come with a pony.

    Seriously, though, I’d really like to see some refactoring in django.contrib.comments to make it easier to extend without hacking the source; Jacob told me my article on that will be obsolete soon, so hopefully I can mark that off the list.

    I’d love to have something better than get_absolute_url.

    Oh, and I want a TimeZoneField. But that's just something I ran into the other day, and I'm working on implementing it.

  3. 003 // Jeff Croft // 07.20.2006 // 11:48 AM

    James…what would be better than get_absolute_url? Not that I'm in love with get_absolute_url, but I'm just wondering what you would do to improve it.

  4. 004 // Brent O'Connor // 07.20.2006 // 11:50 AM

    I agree with 5 & 6. I had a lot of problems with installing the Django enviroment on my Redhat E 3 box. That’s not really Django’s fault per say. That’s mostly Redhat’s problem with not having more rpm’s available. Thanks again for the help with getting it setup Jeff and Matt.

    I setup up Django on a Debian sarge box which was much easier!

    I wish their were more details to help people that are new to Django and Python to help them understand PYTHONPATH and DJANGO_SETTINGS_MODULE.

  5. 005 // James Bennett // 07.20.2006 // 11:55 AM

    It’s one of those long-standing “we wish there was a better way to do this” things. Given an object, you need a way to get the URL of the object, and get_absolute_url does that, but with some disadvantages:

    • It puts URL configuration in two places: part of it in urls.py and part of it in the model definition.
    • It makes it dangerously easy to get stuck in a URL scheme, since get_absolute_url needs to return the full path above the object as well (e.g., if you want to re-use a some weblog models on another site, but have them live under, say, /thoughts/ instead of /entries/, now you have to change their get_absolute_url to reflect that.

    There’s a really old ticket in the Django Trac for this, but still no consensus on a fix.

  6. 006 // Matt Croydon // 07.20.2006 // 12:06 PM

    James,

    It isn’t pretty, but setting ABSOLUTE_URL_OVERRIDES will allow you to get around different absolute urls on different sites.

    I agree though, I’d love a better way to do it.

  7. 007 // Thomas M. // 07.20.2006 // 12:30 PM

    Jeff, I could somewhat
    add to that list … while I haven’t had time to find a solution to my specific problem, I also give an explination of what might help someone like me - who relishes more interactive, visual, video “screencast” tutorials. Sometimes I never know when something is replaced, modified, totally taken out, or when I’m looking at a completely different item all together. But, that’s just me being totally dense at times.

    I really do hope to try my hand futher at Django, in the coming months, but at this point it’s very hard finding time to learn “something completely different” (woah, Monty Python is perfect for Python) ;-)

  8. 008 // Steven Ametjan // 07.20.2006 // 12:34 PM

    One of my biggest problems is the fact that USStateField just creates a text field rather than a dropdown that’s pre-populated with the 50 state abbreviations. I know that I could create a simple piece of javascript to change it, and create the proper options, but I would think something that is validating that something is a proper abbreviation would also be able to just generate the list for you.

  9. 009 // Ryan Berg // 07.20.2006 // 12:48 PM

    As a geeky designer, rather than a real programmer, it certainly took me a while (and the help of a programmer friend) to get past some of the hiccups of getting a Django dev environment up and running.

    An executable Django environment, a la Locomotive for Rails, could go a long way in getting designers straight into learning and developing in the django framework, rather than fighting with python paths and database hooks.

    Maybe one of the more experienced Django-ites (is there a term to refer to someone who does the Django?) could shed to light on if this is a really good, or really bad idea.

    I know this wouldn’t be suited for a deployed production environment, but could be great for initial development.

  10. 010 // Harish Mallipeddi // 07.20.2006 // 1:01 PM

    My first priority from the list above will also be the first item on the list.

    All that beautiful ORM is useless, if it cannot automatically adapt itself to subsquent changes because it is important to note that nobody decides upon all the features that they want for their site right in the beginning. And hence it is really hard to get the db schema 100% complete in the beginning.

    Considering the fact that a majority of time is spent in maintaining the site and rolling in new features, the current ORM support helps Django developers only for the first 10% of the development period of any site.

    Hopefully the SoC project turns out to be a success!

    Cheers, Harish

  11. 011 // CoolGoose // 07.20.2006 // 1:20 PM

    Well let’s hope that someone will fix this thigs. Remember anyway that django isn’t 1.0 yet for a good reason: everyone knows about this problems :D

  12. 012 // Jake // 07.20.2006 // 1:26 PM

    Documentation is amazing. Template and model system is great. Manipulators take some time to get your head around.

    I am sure this has come up 8000 times already. Where is the easy ajax support?

    Yes, I went there. :-)

  13. 013 // Nathan Borror // 07.20.2006 // 1:32 PM

    Since I switched most of the questions I received revolve around #5. I think screens cast could aid.

    Stop caching that admin tool :)

  14. 014 // James Bennett // 07.20.2006 // 1:45 PM

    Matt: yeah, I know. I just wish there was something better ;)

    Harish: it’s far from “useless”; there are a number of popular ORM solutions out there which offer no automated schema migration, and they work just fine for what they do. I tend to look at it as an “icing on the cake” feature (but then, I also tend to think that most situations where people say they need lots and lots of schema migrations could be better remedied by good model design up-front).

    Jake: In current Django trunk you can serialize any set of objects to XML or JSON, ideal for doing AJAX. I very highly doubt that any sort of “generate the client-side JavaScript for me” features will ever land in Django’s core.

  15. 015 // Jeff Croft // 07.20.2006 // 1:47 PM

    @James: Makes sense. I can see now, how get_absolute_url isn't perfect.

    @Steven: I agree that it should be a drop-down by default, but the easier way to solve this in the interim is use use choices=WHATEVER in your model, with WHATEVER being a dict of the 50 states and their abbreviations.

    @Harish: I totally agree. Lucky for us, I think everyone agrees, so I’m sure there will be a solution in the future.

    @Jake: There has been quite a discussion going on in the Django community about whether or not “easy ajax support” is a good idea. My personal feeling is that it’s not a good idea. There are already countless good Javascript frameworks that handle this (YUI, Jquery, Dojo, Prototype, etc.) — I don’t see why Django needs to be in this space, as well. I’m for letting the designer/front-end developer handle javascript themselves and/or use one of the existing frameworks that is designed for it.

    @Nathan: I agree on the screencasts. I know Adrian prefers to hold off most of the heavy marketing until 1.0, and that does seem like a wise decision. Hopefully screencasts or similar will be part of the marketing package when 1.0 arrives.

  16. 016 // Baxter // 07.20.2006 // 2:17 PM

    I definitely agree with 5. Installation for the non-Unix guy is frought with potential pitfalls. Simple install would be huge. I still haven’t got it installed on OS X.

    The big one I see that wasn’t mentioned is host support. Not Django’s fault, but host support seems (to me) to be spotty and grudging, even among “Django-friendly” hosts.

    Yeah, Dreamhost, I’m looking at you.

  17. 017 // Tim Child // 07.20.2006 // 2:38 PM

    How weird, this is exactly the list that I would pick and probably in that order. I love the fact that when can contribute now and get things up and running - if I had the time I know I would love to spend more time working on an easy install method.

  18. 018 // James // 07.20.2006 // 3:52 PM

    I think the thing that sucks about Django most is that Jeff won’t shut up about it. :-)

    Though, if I ever convince myself that I have freetime, I’ll try it out.

    Jeff, I feel dirty now.

  19. 019 // Jeff Croft // 07.20.2006 // 4:02 PM

    James — rumor has it you’re not the only one that feels that way. The good news is, I can tell you to fuck right off without feeling guilty. :)

  20. 020 // Luke Plant // 07.20.2006 // 4:23 PM

    Personally, I found that installation on Ubuntu couldn’t have been easier (apt repositories made all the dependencies a breeze, and svn is as easy as falling off a log), and was just what I would have expected and wanted for any piece of software of this sort. And on my live environment, which is shared hosting, it was probably even easier (thanks to WebFaction really).

    But that makes it harder to appreciate what it’s like for those who have to use Django on Windows/Mac, or aren’t used to the command line, and, given that the official release is a tarball not a zip file, I suspect Adrian/Jacob are Unix users, or at least very comfortable with it. Maybe we need some motivated Mac/Windows users to do specific installers for the less fortunate platforms ;-)

    By the way, the comments so far are a great confirmation of the fact that criticism from someone who is known to be a friend is so much easier to take, and so much more constructive! It strikes me that criticising your ‘enemies’ over the internet, if it comes over in any way like it is an attack or a put down, is next to pointless.

  21. 021 // Rob Hudson // 07.20.2006 // 4:26 PM

    2 extra things that are on my list:

    1) Can’t edit passwords directly for users in the admin.

    I’m building a website for a local club and eventually want to be totally hands-off on it. The fact that the web administrator can’t create a new member and set their password is a downer. The website will be members only so a registration system will not be used.

    2) Having to restart Apache when changes get made.

    Is this a mod_python issue? I have my own server so this isn’t a big issue but I’m curious what people do if they are on a shared hosting environment and aren’t able to restart Apache.

  22. 022 // Jeff Croft // 07.20.2006 // 4:31 PM

    Rob:

    God, I don’t know how I forgot the password editing bit. Great one. Thanks for reminding me.

    As for having to restart apache, I do think it’s a mod_python issue. A restart isn’t required using Django’s built-in server, and it’s also not required using FastCGI on Dreamhost (and probably other shard hosting environments). It is required, though, on my Gypsy Hosting account, which uses mod_python. Would be nice if it weren’t required, but I suspect there’s not much that can be done about it from the Django side.

    (To be clear, a restart is only required when Python changes are made…models, views, etc. A restart is not required when template changes are made.)

  23. 023 // Jay Graves // 07.20.2006 // 4:32 PM

    I have also wanted the ability to delete multiple items at once from the admin (#3). So I coded up a quick patch. http://code.djangoproject.com/ticket/2383

  24. 024 // Ian Holsman // 07.20.2006 // 5:06 PM

    re #4. the ‘search’ one.

    Hugo had some code up to do this in his svn, but it is using 0.91, so it’s next to useless for you, of course if you could always sponsor someone to write one for you/for django if it pains you too greatly.

    I’d like to add my own. lack of a default CSS design guidelines. no I’m talking about the fancy logo’s .. just a standard on what names to call things.. kind of like what csszengarden does.

  25. 025 // Steven Ametjan // 07.20.2006 // 6:52 PM

    Kinda following along with what Luke said, one thing that bugs me about Django, is the lack of a program similar to Locomotive. Locomotive helped me out immensely when I was starting out with RoR, and I’m sure if there were something similar for Django, it would help people out a lot. Obviously it wouldn’t be useful for a production environment, but it would certainly aid those that are just working locally that have a fear of the Terminal.

  26. 026 // Joe Heck // 07.20.2006 // 7:09 PM

    I’ve placed a set of instructions for installing a “development version” of django (SQLite support) on MacOS X 10.4 on my blog - step by step if anyone is interested:

    http://www.rhonabwy.com/wp/2006/07/20/installing-django-on-macos-x-development-version/

  27. 027 // SmileyChris // 07.20.2006 // 7:24 PM

    Regarding some of the comments people have been talking about:

    get_absolute_url: Adrian has been working on a much better method than get_absolute_url which basically figures out a url for an object by using the info in urls.py.

    Direct password editing: I just finished a patch for this the other day. If you need it urgently, check out http://code.djangoproject.com/ticket/61.

  28. 028 // Bill de hOra // 07.20.2006 // 8:28 PM

    1: model inheritance

    2: inconsistent unicode

    3: admin app doesn’t have a model builder

    4: committers aren’t scaling to issues/community

    5: surprisingly awkward to find an angle into commiting patches (maybe that’s just me, but it’s hard to know what the committers actually want to focus on sometimes). I seem to be talking myself into the unicode bit

    6: no deployment tools (I’m with Vogels - you build it, you run it)

    7: contrib.search - check. Tho’ i don’t see this being any less contentious than the current tourniquet fest over js libraries. It’s got to be a callout to lucene via the A9 api, right?

    8: having to explain to people Django is production ready now; please land a new rev

    9: too much talk about js (go Bennett); it’s an energy sink

    10: no tee shirts.

    11: “there’s a google summer of code project for that”

    I suspect 4 is the biggest problem now, with 10 a close second.

  29. 029 // Bill de hOra // 07.20.2006 // 8:33 PM

    “But that makes it harder to appreciate what it’s like for those who have to use Django on Windows/Mac, or aren’t used to the command line, and, given that the official release is a tarball not a zip file,”

    It’s fine on windows. The only real awkward bit was switching between mr and trunk a few months back cos windows doesn’t have symlinks. I ended using using junction.

  30. 030 // Tom Haddon // 07.21.2006 // 2:51 AM

    Re: #2 Admin interface/authentication module: inability for a user to edit only objects he/she has created.

    Would also love to have the permission for “view an object” only (in addition to change, add, delete). This would mean I could open up the admin section to a bunch of users that I currently have to code front end pages for.

    Can’t imagine it would be too difficult either. Might have to take myself up on that one if I can find time.

    Thanks, Tom

    PS - love the live comment preview!

  31. 031 // James Bennett // 07.21.2006 // 3:54 AM

    Bill,

    1: yeah, it’s a big nasty problem to implement correctly, but Malcolm is scary smart and working on straightening it out.

    2 , 4 and 5, since they’re somewhat interrelated: I’ve been following the Unicode stuff with interest, but it’s also pretty far from my area of expertise. Georg pretty much single-handedly built our i18n system, but he’s been AWOL just recently. Are you subscribed to django-i18n?

    Scaling the dev team is something we’ve been trying to figure out; my personal favorite suggestion at the moment for kickstarting that is to try to get some reliable people from the community doing bug/patch triage and forwarding things on to the committers when it looks like we’ve got something good.

    3: I could go either way on this one. It’s the kind of feature where I can see it being abused horribly should it fall into the wrong hands (“well, our CTO demanded model-creation rights”) or being a godsend should it stay in the right hands. If someone can make it work, I’d probably vote for it going in.

    6: there are people doing DEBs and RPMs pulled from trunk every so often, and I think that’s probably the way to go for deployment on a server or on a developer’s Linux box. Windows and Mac packages which install all the prerequisites would be lovely, but I’ve not a clue how to go about building such beasts.

    7: yeah, search is hard. Brian’s doing some brilliant stuff, and hopefully we’ll have something workable Real Soon Now(TM).

    8: hard to do until model inheritance is straightened out. I don’t think there are any other showstoppers, though.

    9: I’ve said my piece on JavaScript. :)

    10 I’ve got the original Django t-shirt which was handed out a couple of places, and there’s a new one which, I believe, will make an appearance at OSCON.

    11: Hey, if Google wants to pay smart kids to fix our problems for us, I’m happy to wait a bit while it happens :)

    They all seem to be making good progress, and honestly it’s getting some things done that might get lost in the shuffle otherwise.

  32. 032 // James Bennett // 07.21.2006 // 3:56 AM

    Ha.

    Jeff, sorry about breaking things. Gotta love Markdown interpreting my ‘#’ before each number as an h1.

  33. 033 // Bill de hÓra // 07.21.2006 // 5:06 AM

    James,

    you’ll have to speak up :)

  34. 034 // Kevin Teague // 07.21.2006 // 5:12 AM

    1: permission-based, metadata searching.

    Once model inheritance, row-based permissions and full-text search are sorted out you could then query an app for the common set of metadata that all of your content types share, e.g. Creation Date, Last modified Date, Content Type, Owner, Full-text, Id, Title, etc.

    This would then give Django the same capabilites as Spotlight in Mac OS X or portal_catalog in Plone. Then instead of having to query by content-type you could do:

    allcontent.search(Kind=[‘Blog’,’Photo’,’Link’,], Text=’Django’, LastModified=‘06-21-2006’)[:25]

    This would give you back the 25 most recently edited objects with the text Django in them. Great for rolling all of the feeds-per-content-type into a single feed.

  35. 035 // Oliver Charles // 07.21.2006 // 8:36 AM

    Nice list, I agree with most of them - but at least they aren’t breaking problems!

  36. 036 // Jeff Croft // 07.21.2006 // 12:07 PM

    @Bill:

    First, thanks for your list. And thanks for your comments, in general — I always find your stuff, both here and elsewhere, to be smart and funny, which makes for good comments. :)

    1: I don’t know that I fully understand model inheritance (as in why you’d want it, what it would do for you, etc.), but it seems like a common enough request that I’ll presume I’m just missing something. :)

    3: If a model builder in the admin app could be done well, then I would be all for it. It would obviously rely on good schema migration, which isn’t there now. I think making a good UI for model building is a tricky problem to solve, but the guys at dabbledb have given us a damn good example to go on.

    4: Being as I don’t submit patches, I’ve not dealt with this at all, but if that’s the case, it’s certainly a big problem.

    7: How to implement contrib.search may be contentious, but I don’t think it’ll be contentious that there should be a contrib.search. With the javascript/AJAX bit, we haven’t ever gotten over the question, “Should Django provide AJAX helpers?” :)

    8: Yep, that’s what I was getting at with my number 6. Trying to tell someone, “yes, the latest official version is .91, but you should use the trunk branch development version because of magic removal, and I promise it’s stable even though it’s a pre-release “development” version, etc.” just sounds…well, shady. I don’t blame people for having a perception of Django as immature. Just packaging up trunk into a tarball and calling it .95 so the documentation on the site actually matched the release version would go a long way.

    11: Although it is annoying to hear “there’s a Google Summer of Code project for that” as the answer to so may questions, I’d rather hear that than “there are no plans in the future for that feature.”

  37. 037 // Jeff Triplett // 07.21.2006 // 1:43 PM

    I’ve used Django for about two months and these are fresh in my mind:

    Download ‘“ just having a nightly or weekly snapshot would go a long way in helping new people find the right version without committing it to an official version.

    caching ‘“ Performance wise, caching works great, but I noticed that my admins acted funny with caching turned on. I eventually separated the admins out and started using a copy without catching turned on to get around this because I grew tired of hearing people complain about changes not showing up in the list pages. I would have thought that these areas would not be cached. It would be nice to have the option of don’t cache this area of my site so that it would work.

    contrib.search - It would be nice if there was both website and app level searching that I can drop hints to in the models or meta layer. Then using the search model could be a matter of including the contributed / model like comments do. Everything else seems to just work and this would make searching ultra-easy. I know this is a work-in-progress’¦

    form manipulators - While I really liked the model code, I found myself heavily modifying some of the user contributed manipulator.py / scaffold.py files to better fit my needs. I like the generic crud views but I’ve had a hard time finding a practical use with my forms for them so I ended up going back and writing my own custom ones. Just having better integration between models and the custom manipulator form fields would be nice to see. Again, you can use the crud generic view template to help write a custom one but it would be nice to have something more in the middle. Personally, writing form manipulators is my least favorite thing to do in Django.

    model.migration (evolution) ‘“ When I first looked at the whole model/meta system I thought I’d hate it, but instead I now see the light. The process of changing a model is simple and in theory, adding / removing a field should be a straight forward / simple process should be simple to handle. When you have foreign keys, etc. it’s now a much more complex problem to deal with.

    I’ve tried the sql/{modelname}.sql method that is outlined in the documentation and it didn’t help me solve my problem. If this hook instead looked for a python module to run ( sql/{app}.py ) then I believe that would allow for some greater flexibility when using the manage.py db options.

    Most of time I have data before I have an app, so I’m used to importing in / out of Excel into tsv files (client we deal with always have tons of data and never want to key in thousands or even dozens of entries). Between Python and Django I can have a data import in about 5 minutes using tsv/csv (you could easily use xml). I have a more generic version that knows how to handle field lookups in other models based on how they relate to one another.

  38. 038 // David Avraamides // 07.21.2006 // 7:17 PM

    I agree with many of the others: inheritance, model migration, search, installation, …

    But theres one I didn’t see: aggregation support in the DB-API. I may be in the minority, but I am building apps that show large numbers of small records with lots of numeric data that often needs to be sliced, diced and grouped. I have to drop to custom SQL and build the results into something compatible with templating.

  39. 039 // Brandon Harper // 07.21.2006 // 11:19 PM

    Good to see constructive criticism of Django by someone so close to it. I’d say the top of my list is also #1— I find that it slows down my development to try and get my models right out of the box to make sure I’m not having to do a bunch of manual SQL, etc. Hopefully the Google Summer of Code will prove to be fruitful for Django.

    And yes, isn’t it time for another release already instead of doing ‘svn update’ a few times per week? ;)

  40. 040 // Mark Hurty // 07.23.2006 // 12:44 AM

    Installation: Here’s a problem…I don’t have access to the sudo command on my hosting service and the Django instructions conclude with this step:

    sudo python setup.py install

    How does one work around this problem?

  41. 041 // Armin Ronacher // 07.23.2006 // 4:28 AM

    I’ve another thing that really sucks: doesn’t support WSGI like it should. It’s impossible to serve a django application on any other url than “/”, get_absolute_url() can’t get access to a request object to find the SCRIPT_NAME and you can’t have multiple django projects in the same python process.

    That really sucks.

    Regards,
     Armin

  42. 042 // Amr // 07.24.2006 // 1:04 PM

    re: #1, I would say the syncdb should have two options. One is “Create”, the other is “Alter” and so when you change your class defintion and run synchdb, you could say something like syncdb ALTER classnameThis way, the data won’t be lost, as synchdb would automagically ALTER as opposed to just dropping and recreating the table.

    Alters can be: 1) In-Place — Alter table add column etc. 2) drop-create — create new table with new column, insert from old into new table, drop old table

    am I missing something? too simplistic?

  43. 043 // Mark // 07.25.2006 // 3:19 PM

    ALTER is fraught with peril, basically. What do you do to a table if you want to add a non-NULL field? What if your new field description chops off some contents of the old field’s information?

    I suppose this would be the automagical portion of the fix. :)

  44. 044 // tuisu // 07.27.2006 // 3:36 AM

    I agree with most of the comments but what bugs me most is why URLField isn’t showing up as an URL in admin?

  45. 045 // Tyson Tate // 07.27.2006 // 12:28 PM

    @Mark Hurty

    The install script simply packages Django’s code and tosses it in your Python installation’s site-packages directory.

    All you really have to do is add the django/ folder (i.e. django_svn/django/) to your PYTHONPATH and you’ll be good to go.

    The following article has more info: http://wiki.dreamhost.com/index.php/Django

    Although it’s Dreamhost-specific, I was able to do roughly the same thing to get my Django set-up working on Bluehost.

  46. 046 // Seth Thomas Rasmussen // 07.27.2006 // 12:29 PM

    I find your points about the admin interface interesting. To me, it reads like something that is going to become a great nuisance down the line, as people request it to do more and more. I also find it interesting that Django seems to foster the notion of patching the core to add deletion of multiple items at once, for example, instead of simply making it easier to adjust to those inevitable customisation needs.

  47. 047 // Jeff Croft // 07.27.2006 // 12:38 PM

    Seth-

    The admin interface is wonderful, overall. I’ve got a few minor quibbles with it — but what app do you use that you don’t have a single quibble with?

    Bottom line — with Django, you get a fully-functional, working admin interface for free. If it’s not perfect for you, you don’t use it. With any other framework (or when writing web apps without a framework), you don’t get an admin interface at all — you always have to build you own.

    So what’s better? Django’s entirely optional admin interface that is good enough to handle 90% of the apps you’ll ever write, or no admin interface all at?

  48. 048 // Seth Thomas Rasmussen // 07.27.2006 // 1:29 PM

    I just find the design approach of enabling you to recreate these common elements with a minimum of fuss rather than handing you a bunch of stock widgets more progressive and useful. I haven’t used Django, so I can’t speak to the customisation options, but I just noticed a few comments in this thread pointing toward fixing the communal kitchen sink instead of teaching everybody how to make their sink their own.

    Again, I’m not a Django user, so I’m reacting mostly to things like this post, these comments, what I read from Python programmers, etc. If anybody feels I’m way off base, please do chime in.

  49. 049 // Seth Thomas Rasmussen // 07.27.2006 // 1:31 PM

    Bah, my comment about design approaches is confusing. To be clear, stock widgets have their place. I guess my impression is that the scope of the Django out of the box admin seems unecessary for my tastes.

  50. 050 // Jeff Croft // 07.27.2006 // 1:59 PM

    Seth,

    You do realize that Django’s admin interface is not a core piece of Django, right? It’s a separate Django application that is optional, and not installed by default. Django offers several of these included-in-the-distribution-but-not-installed-by-default apps.

    If you want to make your own admin interfaces (as you would in Rails), you’re more than welcome to. Django doesn’t hold you back from that at all.

  51. 051 // Seth Thomas Rasmussen // 07.27.2006 // 2:11 PM

    Like I said, I’m not very familiar, so the reasonable assumption is that I didn’t realise that, eh? ;)

    To be fair, I think the Django marketing is misleading then, but whatever.

    So, the admin interface is something like a plugin or extension kind of concept then is it?

  52. 052 // Jeff Croft // 07.27.2006 // 2:37 PM

    The admin interface is an application. It’s just a regular Django app that gives you CRUD views of all the objects in your database. I guess you could think of it as a plug-in or extension, but in Django’s terminology, it’s an application.

    It may be relevant to note that Django makes a differentiation between “projects” and “apps.” For example, “jeffcroft.com” could be a project, and apps it might include would be “blog,” “comments,” “admin interface,” “tumblelog,” etc.

    Some of the other included-but-not-installed-by-default apps (which reside in django.contrib) are an authentication/authorization system, a generic comments tool (for enabling comments on any type of object in your database), a syndication framework that makes it easy to generate RSS/Atom feeds of object in your database, a “flatpages” app for simple pages of static content that is storied in the database, and a session tracker. All of them are optional, but available with a one-line install if you want them. The idea is to provide tools that are needed on a large percentage of websites (for example, almost every site/app needs feeds and auth/auth) to take away some of the pain of creating these things over and over again with each new project. But, in all cases, if you wanted to write your own instead of using the included ones, you’re more than welcome to. They’re just there if you want them.

    As for the marketing being misleading — I dunno. Everything in Django is modular. Everything is piece-by-piece so you can use the bits you want and not the bits you don’t. All of these django.contrib apps are just more pieces that can be added to the stack, if you want. They’re optional — but everything is optional in Django.

    So, if it’s misleading to say that Django includes an admin interface because that admin interface is optional, it’s also misleading to say that it includes ORM and a template language, because they’re optional too.

  53. 053 // Seth Thomas Rasmussen // 07.27.2006 // 6:09 PM

    Hmm. These “apps” are more compelling now that you’ve put it that way.

    I wonder though.. considering say the comments app and the admin app.. does the comments app have administration capabilities, or would you have to update your admin app when adding another?

  54. 054 // Jeff Croft // 07.27.2006 // 6:20 PM

    Seth-

    The admin app has the ability to administer objects from any other application. So, yes, it works great for administering (adding, removing, editing) comments. If you’ve got the admin app installed, you can see objects from every other application in there (unless you don’t want to).

    So, in the admin app for jeffcroft.com, I’ve got views of blog entries, comments, tags, flickr photos, ma.gnolia links, sudoku puzzles, etc. — every object in the database is viewable in the admin area.

  55. 055 // Jan B. // 08.01.2006 // 11:22 AM

    I wholeheartedly agree on #1 and #2.

    Especially #2 drove me nuts, with glue code and wrappers around GenericViews all over the place.

  56. 056 // Peter Bowyer // 08.15.2006 // 5:19 PM

    @Harish, @James, @Jeff: with regards to database schema management, please have a look at what Lukas Smith is doing with MDB2_Schema. It’s been developed over 7+ years (?) and is definitely worth evaluating.

  57. 057 // django forums // 09.25.2006 // 8:15 PM

    Nice to see the head designer of Django to admit its faults. Nothing is perfect as I’ve learned, every language has its little quirks.

  58. 058 // Jeff Croft // 09.25.2006 // 8:27 PM

    I am by no means the “head designer” of Django. in fact, I have no official position in the Django community. I’m simply a Django user.

  59. 059 // Henrik // 10.31.2006 // 9:28 PM

    1. The expectation that the model is saved with one primary key that is probably going to be an integer. Even with the single field primary key restriction, I would expect a way to support custom allocation strategies for the value.

    2. Why am I forced to use a command line. Why not just set up a Django server and support all admin/sync/reload from there?

  60. 060 // Jeff Croft // 10.31.2006 // 10:17 PM

    Even with the single field primary key restriction, I would expect a way to support custom allocation strategies for the value.

    Hmm, maybe I’m misunderstanding you, but this doesn’t seem like a limitation to me. You can choose any field in your model to be your primary key, so there’s no reason it has to be an integer, and you should be able to allocate it however you wish — right?

    Why not just set up a Django server and support all admin/sync/reload from there?

    If by “Django server” you mean have Django’s built in web server (rather than Apache/LigHTTPd/whatever) serve up an administration interface for this stuff, that seems like a bad idea to me. No way Django’s built-in web server can be expected to serve up pages as well as, say, Apache.

    And if by “Django server” you mean make these functions part of the admin interface — well, it’s a good idea (and definitely something that has been considered) — but I’d sure hate to see the command line taken away. I heart the command line, and Django should never require you to use its admin interface.

  61. 061 // Dan Kelley // 01.05.2007 // 6:35 PM

    Item #5 is spot-on. Deployment with real servers (i.e. not the test server) is more difficult than other casual-administration task of analogous interest. Deployment is also quite boring (unlike, say, learning Python or Ruby), and I think this matters more than one usually admits in polite conversation.

    The deployment chapter of the Django book (http://www.djangobook.com/en/beta/) will be very welcome, when it arrives in mid-January 2007. I’ve given up looking at the other chapters until I see some semi-official instructions for setting up a server on OS X. (Why marvel at all those shiny cuff links when it’s not clear whether you’ll be wearing a long-sleeved shirt?)

    Context: my remarks stem from my experience with OS X on my personal machines. Rumour has it that the next OS X release will support RoR out of the box, and that may not be a good sign for Django on the platform.

  62. 062 // Brandon // 04.14.2008 // 12 PM

    For those of you who are having deployment issues in a shared environment, check out WebFaction. I was having a hell of a time getting things to run at all at my previous host.

    WebFaction has gui-based tools to deploy Django, and I had my apps up and running very, very quickly. They also have excellent support for Rails, PHP, TurboGears, WordPress and a few others.

  63. 063 // Adrian // 07.24.2008 // 8:07 AM

    Not only that, but two years later, we’re still waiting for version 1.0 while Rails has undergone several serious changes and adaptations.

    Oh, and don’t rely on the trunk; it receives breaking changes as often as every month. Good luck fixing your code for that.

    Nice article! Very relevant after 720 days. But that’s not all that sucks about this framework: you forgot the support of REST APIs; the coupling between views and templates in Django is in my opinion a big, big mistake. I’m maintaining a big application (±40 KSLOC) written in Django and maintenance is a nightmare, much much worse than what you think.

    And deployment is, well, even harder than Rails. And setting up developer machines. And I will stop here. I deeply hate Django.

  64. 064 // Trevor Caira // 07.26.2008 // 11:14 AM

    Re “what could be better than get_absolute_url":

    Jinja2. Put a url() method in your model: 

    class MyModel(Model):
    def url(self, *args, **kwargs):
        return reverse('myapp-mymodel_detail', args=args, kwargs=kwargs)

    And in your template: 

    {{ model_instance.url('arg1', 'arg2') }}

Post your comment