Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Django Newbie Mistakes

code.djangoproject.com

Post reply on HN
Print view View original

61–70 of 225 posts

Re: Django Newbie Mistakes

#61

Post by alasdairnicol »

tiglionabbit wrote: post #44

A lot of these things are only common mistakes because of Django's unusual behavior. > POST to views loses POST data The middlewares shouldn't be redirecting POSTs then! They could have returned a client error instead. > Blank object names They could have provided a fallback of __class__.__name__. > Integer & NULLS If the admin interface knows the field is required, why does it even attempt to insert a null value? It…

> The middlewares shouldn't be redirecting POSTs then! They could have returned a client error instead.

This has been fixed since Django 1.0, released in 2008. The page links to the commit that fixed the issue.

Re: Django Newbie Mistakes

#62

Post by publicfig »

akx wrote: post #21
n0us wrote: post #2

If you're writing a REST api, invest the time to learn Django Rest Framework. It is well worth it.

DRF is nice enough 90% of the way, but when you need to do something that its authors haven't really thought of, you need to dig in very deep to fix things, I've found. :/

I had that issue for a while, but lately I've really just found that 95 times out of 100, I can accomplish everything I want to do with just a .to_native() and using whatever method I see fit. I know it's not always the most optimal way, but leveraging that allows me to really use DRF for so many projects and get it up easily and without too much hassle.

Re: Django Newbie Mistakes

#63

Post by adpirz »

My favorite opinionated boilerplate for new Django projects: https://github.com/pydanny/cookiecutter-django/

From the author of the great Two Scoops of Django series. https://www.twoscoopspress.com/products/two-scoops-of-django...

Two great ways to avoid some newbie mistakes. Although some could argue diving into boilerplate without understanding it is in fact a newbie mistake itself.

Re: Django Newbie Mistakes

#64

Post by alasdairnicol »

cimmanom wrote: post #34
alasdairnicol wrote: post #7

Django’s documentation is excellent, but parts of the wiki are out of date. This page has barely been updated in the last four years. It mentions MIDDLEWARE_CLASSES (deprecated in Django 1.10) and using strings in url() (deprecated in Django 1.8). There may well be other bits which are out of date. The entries in the faq [1] are more likely to be kept up to date. [1]: https://docs.djangoproject.com/en/2.0/faq/

The wiki (at code.djangoproject.com/wiki) is community-maintained, and not part of the official documentation, and yes, very often out of date. The official documentation (at docs.djangoproject.com) is scrupulously maintained, and excellently written.

Thanks for the clarification. My point was that this wiki page is out of date so probably not that useful. I could have been clearer that the wiki is not part of the official documentation.

Re: Django Newbie Mistakes

#65

Post by rrauenza »

Is mylist = []; mylist == [] really a thing for testing for an empty list? Seems very unpythonic.

My newbieish mistake was assuming (forgetting!) that NULLs aren't distinct/unique, so you can not enforce a nullable column unique and expect only a single NULL value. There is a way around it with conditional constraints ... but unique=True or unique_together is not it.

It's really an RDBMS thing, not a Django thing, but when Django abstracts away the RDBMS, one forgets.

Re: Django Newbie Mistakes

#66

Post by StavrosK »

jtchang wrote: post #36

One of the things that makes me sad is there is no project even remotely close comparable to Django for say Golang or Scala. I love the fact that you get an admin interface out of the box. And tons of documentation. The views/template stuff is a bit dated since everyone started moving to frontend/backend services and SPAs but we still have DRF which is incredible in the amount you get for "free". I've had the "pleasu…

This is exactly my view as well. Every time I've used Flask, I ended up regretting it, because I've invariably needed to fit something to it that would have worked out of the box with Django (or at least integrated much more easily).

I haven't found any reason to use Flask in a project, except maybe for small, ad-hoc scripts that you want to run in a single file.

Re: Django Newbie Mistakes

#68

Post by macroexpanse »

jtchang wrote: post #36

One of the things that makes me sad is there is no project even remotely close comparable to Django for say Golang or Scala. I love the fact that you get an admin interface out of the box. And tons of documentation. The views/template stuff is a bit dated since everyone started moving to frontend/backend services and SPAs but we still have DRF which is incredible in the amount you get for "free". I've had the "pleasu…

Scala / Play Framework does in fact have an out of the box solution for this: https://www.playframework.com/documentation/1.2.2/crud

Edit: This was removed in Play Framework 2

Re: Django Newbie Mistakes

#69

Post by jonknee »

Great post, though this bit stuck out for me:

   current_zip = meta.IntegerField(max_length=5, blank=True)
You should not store zip data as an integer as they can start with 0. Zip codes use numbers, but aren't actually numbers themselves (leading zeros, no arithmetic, etc). Plus, someday you'll want to ship something to Canada.

Re: Django Newbie Mistakes

#70

Post by scrollaway »

jonknee wrote: post #69

Great post, though this bit stuck out for me: current_zip = meta.IntegerField(max_length=5, blank=True) You should not store zip data as an integer as they can start with 0. Zip codes use numbers, but aren't actually numbers themselves (leading zeros, no arithmetic, etc). Plus, someday you'll want to ship something to Canada.

Even full canonical US zip-codes are 10 characters, right? XXXXX-YYYY or something

Edit: I think it's a typo and meant to be a CharField. There's no such thing as IntegerField max_length.

Post reply on HN