Django: places to avoid

Django: places to avoid

Year ago we started using Django as mainstream technology for all our company on-going development. After a great amount of discovering great sides of Django, now its a time to also discuss some troubles we've had with it, and how we are trying to solve them.

Bug management issues

To me, the biggest trouble so far is Django bug-management. What really surprised me, is the technique how bugs are closed. There were a few cases, when actual, active bugs are closed as either "Invalid" or "Wontfix" with remark: "XXX will be replaced with YYY some time later, so we won't spend our resources on fixing this bug, not depending how small it is". Years come, and bug is still affecting main branch, and nobody is fixing it.

There could be hundreds of such "hidden" bugs which were discovered by different developers, reported to Django bug-tracking system, and then closed by some strange reason. I don't think its normal or acceptable. I think, if bug is not fixed, it should stay open. Other people come, see bug, take patches, use them when appropriate. That would not be possible when bug disappears.

Examples of such "invisible" bugs:

Do you need more examples?

Places to avoid in Django

After spending some time with Django, I've found a few common places, where bugs are never going to be fixed. I would like to explain those, so may be it helps others to avoid such problems.

The biggest number of issues we've experienced so far were related to a small amount of Django code. Mostly, *one thing you should never ever use in your Django project is OneToOne fields*. That makes a real trouble for your life, but very handy when you would like to extend your models on-the-fly. If you are real masochist, here is a list of patches to Django, (some of which will never be accepted due to NFA is coming … may be in a few years …): http://djwarehouse.org/browser/djWarehouse/trunk/docs/patches.

Another thing you should never make is to name your applications with lower case letters and not overriding 'db\table'. We have so big amount of problems due to half working ORM at this part, that we have seriours plans to rename all our already deployed tables, just to avoid this problem in future

If you follow those 2 restrictions, probably you would not have any big problems with Django. While I will be continuing talking to Django developers, asking not to close current active bugs, which hurt current trunk.

Conclusion

It seems main developers have chosen the direction where they go, and thy don't have time or will to fix old issues. Normally, they say: "Use NFA over oldforms-admin". Now, I think that I have to invest some time into investigating some long-awaited but 'not-yet-ready' Django parts, to try to use them in production. Exactly:

  • Newforms-admin
  • Queryset-refactor branch
  • Django-inheritance (to replace OneToOne where possible)

I've tried NFA year ago, and it was performing pretty badly. Hope something is changed after a year of development… What about branches, I dont' see a way how to use them altogether… Needs a little research.

Update 2008.04.29: since Django queryset-refactor branch has been merged, and they are actively using OneToOne fields, it seems most of problems with OneToOne fields disappeared, or disappear very soon.

Comments

Comments powered by Disqus