SQLite databases don’t care about your using of max_length on your models. Let’s look at an example.

models.py

1
2
class Book(models.Model):
    title = models.CharField(max_length=30)

Now, we’ll run some queries.

1
2
3
4
5
6
7
8
9
10
11
$ ./manage.py makemigrations
$ ./manage.py migrate
$ ./manage.py shell
>>> from book.models import Book
>>> title = 'A' * 31
>>> print len(title)
31
>>> book = Book.objects.create(title=title)
>>> book.save()
>>> len(book.title)
31

When running SQL queries using SQLite, you find that you can create records and the database will save a CharField with attributes with bigger strings than what the max_length describes.

Is there any way we can fix this? Sure there is!

When was the last tutorial you’ve taken? It could have been my Free Email Course about Django REST Framework, or it could have been the “Official Django Tutorial” that will have you go through a simple Django Application.

What did you think about these tutorials? Which one helped you to learn the best? Why did it help you learn?

I’m not saying my course is the best, ever. Far from it. However, it was an experiment to see if tutorials can be better, or not.

This is an opinion piece about my feelings about tutorials and how it might be possible to make them better.

If you do a tiny bit of lurking on Django forums, it seems like EVERYBODY is going nuts over learning how to create a RESTful API in Django using Django REST Framework. I’m fastinated by this craze. So, I wanted to start a conversation about why YOU might want to learn how to create a RESTful API.

You might want to pay attention, I have a fun surprise at the end of this post.

So, you crazy people and your new fangled RESTful API technologies, need to understand what you need to know about REST and why it might make sense to use it.

Awesome! You made it! You’re here because you don’t want to do the same mistakes that every other newbie makes.

The first step to becoming a real developer and not just a newbie, is by understanding the mistake that you’re going to make and then prevent it from happening! And, almost every newbie commits this mistake until they actually decide to humble themselves with the process of learning.

Don’t try to learn Django until AFTER you finish this blog post. Why? Because you WILL not commit the mortal sin of Django newb.

Sometimes it doesn’t make a lot of sense why some things work in Django and others don’t. For example, a ChoiceField has a choices parameter where you can pass in a set of choices and your form will become a select field in your template.

The Django docs says the following:

1
2
3
choices

...an iterable (e.g., a list or tuple) of 2-tuples to use as choices for this field...

Therefore, some people might write the following:

1
dropdown = forms.ChoiceField(choices=[(1, "Option 1"), (2, "Option 2")])

According to the Django docs, this makes a lot of sense. However, what about if you have a function the returns the same thing? Wouldn’t it might makes sense to write it like this?

1
2
3
4
def choice_list():
    return [(1, "Option 1"), (2, "Option 2")]

dropdown = forms.ChoiceField(choices=choice_list())

We’ve all done this before. We learn about class-based Generic Views in Django and we want to use them immediately in our code. Without reading all the way through the documentation, you make the switch.

Suddenly, you’re not really sure how to add additional data to your templates. Maybe class-based Generic Views aren’t really what they were cracked up to be?!

You’re trying to create a Generic View that lists all the tags available for your blog. However, maybe you want to list the tags in the same place as all your posts.

In a fit of rage, maybe you’ve tried to code the following:

1
2
3
4
5
6
7
class BlogIndex(ListView):
    queryset = Post.objects.published()
    template_name = "index.html"

    def get_tags():
        tags = Tag.objects.all()
        return tags

You’re thinking this will allow you to call the function to get the tags inside of a template using something like {% for tag in view.get_tags %}.

You have a variable in a template that holds a filename. Then, you want to pass the variable to your template so that you can put the filename in an <img> tag and render it from staticfiles.

You try doing something like this:

1
<img src="{% static 'mysite/{{filename}}' %}" width="100" height="100" />

However, this doesn’t work at all! What do you do? You know that the variable holds the filename. You take out the static tag and just try:

1
<p>{{filename}}</p>

This prints the filename that you expect. What are you doing wrong? Is there a way I can get around this?

Sometimes the admin site works great out of the box. Other times, you need to add some custom code to certain parts of your admin site.

Maybe, you want some custom tables that shows your revenue for the month (i.e. you have an e-commerce site), maybe you’d like to create a button so you could upload batch SKUs for product inventory in your e-commerce site.

The sky really is the limit. This post will show you not only how to update and custom the admin templates, but it will also give you a clue to how to update the actual admin views so you can change the behavior of the entire admin interface.

As a Computer Science major, we never learned formal web development until you get a job somewhere where you’re tasked to build websites. But, the very act of building websites right out of college, did wonders for actually learning Django. There is too much to know about website building and Django in particular to “know” everything. Therefore, you really need to start out small and work your way up. Sometimes the best way to learn, is not to read and do tutorials, but to actually open a command prompt and:

1
$ django-admin startproject my_awesome_experimental_project

Then, you take what you learned in the tutorials and your try to build something that somebody you know would think is “SUPER COOL!!”. The problem is, you’re not sure where to start. Everybody enjoys tutorials because when you’re going through a tutorial, you’re making things happen. You don’t have to constantly worry, “am I doing this correct?”. Eventually, a project is finished and you can marvel at how awesome it is. Then, after a few minutes playing around with your creation, you think to yourself, “now what?”.

You have a database, you have a Django project and a couple third party Django apps that you installed. You create your models, and now you want to try to test a few queries to see if your models are actually going to work.

Where do I start? How can I test to see if my models are going to work? I wish I could access my database to run some SQL queries with Django to see them in action!