When I read Django code I often see in models what is called a “slug”. I am not quite sure what this is, but I do know it has something to do with URLs. How and when is this slug-thing supposed to be used?
A “slug” is a way of generating a valid URL, generally using data already obtained. For instance, a slug uses the title of an article to generate a URL. I advise to generate the slug by means of a function, given the title (or another piece of data), rather than setting it manually.
An example:
<title> The 46 Year Old Virgin </title>
<content> A silly comedy movie </content>
<slug> the-46-year-old-virgin </slug>
Now let’s pretend that we have a Django model such as:
class Article(models.Model):
title = models.CharField(max_length=100)
content = models.TextField(max_length=1000)
slug = models.SlugField(max_length=40)
How would you reference this object with a URL and with a meaningful name? You could for instance use Article.id so the URL would look like this:
www.example.com/article/23
Or, you might want to reference the title like this:
www.example.com/article/The 46 Year Old Virgin
Since spaces aren’t valid in URLs, they must be replaced by %20, which results in:
The term “slug” has to do with casting metal—lead, in this case—out of which the press fonts were made. Every paper then had its fonts factory regularly re-melted and recast in fresh molds, since after many prints they became worn out. Apprentices like me started their career there, and went all the way to the top (not anymore).
Typographs had to compose the text of an article in a backward manner with lead characters stacked in a wise. So at printing time the letters would be straight on the paper. All typographs could read the newspaper mirrored as fast as the printed one. Therefore the slugs, (like snails) also the slow stories (the last to be fixed) were many on the bench waiting, solely identified by their fist letters, mostly the whole title generally more readable. Some “hot” news were waiting there on the bench, for possible last minute correction, (Evening paper) before last assembly and definitive printing.
Django emerged from the offices of the Lawrence journal in Kansas. Where probably some printing jargon still lingers. A-django-enthusiast-&-friendly-old-slug-boy-from-France.
The term ‘slug’ comes from the world of newspaper production.
It’s an informal name given to a story during the production process. As the story winds its path from the beat reporter (assuming these even exist any more?) through to editor through to the “printing presses”, this is the name it is referenced by, e.g., “Have you fixed those errors in the ‘kate-and-william’ story?”.
Some systems (such as Django) use the slug as part of the URL to locate the story, an example being www.mysite.com/archives/kate-and-william.
Even Stack Overflow itself does this, with the GEB-ish(a) self-referential https://stackoverflow.com/questions/427102/what-is-a-slug-in-django/427201#427201, although you can replace the slug with blahblah and it will still find it okay.
It may even date back earlier than that, since screenplays had “slug lines” at the start of each scene, which basically sets the background for that scene (where, when, and so on). It’s very similar in that it’s a precis or preamble of what follows.
On a Linotype machine, a slug was a single line piece of metal which was created from the individual letter forms. By making a single slug for the whole line, this greatly improved on the old character-by-character compositing.
Although the following is pure conjecture, an early meaning of slug was for a counterfeit coin (which would have to be pressed somehow). I could envisage that usage being transformed to the printing term (since the slug had to be pressed using the original characters) and from there, changing from the ‘piece of metal’ definition to the ‘story summary’ definition. From there, it’s a short step from proper printing to the online world.
(a) “Godel Escher, Bach”, by one Douglas Hofstadter, which I (at least) consider one of the great modern intellectual works. You should also check out his other work, “Metamagical Themas”.
Slug is a newspaper term. A slug is a short label for something, containing only letters, numbers, underscores or hyphens. They’re generally used in URLs. (as in Django docs)
A slug field in Django is used to store and generate valid URLs for your dynamically created web pages.
Just like the way you added this question on Stack Overflow and a dynamic page was generated and when you see in the address bar you will see your question title with “-” in place of the spaces. That’s exactly the job of a slug field.
The title entered by you was something like this -> What is a “slug” in Django?
On storing it into a slug field it becomes “what-is-a-slug-in-django” (see URL of this page)
“Slug” is a newspaper term, but what
it means here is the final bit of the
URL. For example, a post with the
title, “A bit about Django” would
become, “bit-about-django”
automatically (you can, of course,
change it easily if you don’t like the
auto-generated slug).
It’s a descriptive part of the URL that is there to make it more human descriptive, but without necessarily being required by the web server – in What is a “slug” in Django? the slug is ‘in-django-what-is-a-slug’, but the slug is not used to determine the page served (on this site at least)
classArticle(models.Model):
title = models.CharField(max_length=100)
slug = models.SlugField(max_length=100)
如果您想使用标题作为标题，django有一个简单的函数称为 slugify
from django.template.defaultfilters import slugify
classArticle(models.Model):
title = models.CharField(max_length=100)def slug(self):return slugify(self.title)
如果需要唯一性，请添加unique=True子弹字段。
例如，从前面的示例中：
classArticle(models.Model):
title = models.CharField(max_length=100)
slug = models.SlugField(max_length=100, unique=True)
Slug is a URL friendly short label for specific content. It only contain Letters, Numbers, Underscores or Hyphens. Slugs are commonly save with the respective content and it pass as a URL string.
Slug can create using SlugField
Ex:
class Article(models.Model):
title = models.CharField(max_length=100)
slug = models.SlugField(max_length=100)
If you want to use title as slug, django has a simple function called slugify
from django.template.defaultfilters import slugify
class Article(models.Model):
title = models.CharField(max_length=100)
def slug(self):
return slugify(self.title)
If it needs uniqueness, add unique=True in slug field.
for instance, from the previous example:
class Article(models.Model):
title = models.CharField(max_length=100)
slug = models.SlugField(max_length=100, unique=True)
Are you lazy to do slug process ? don’t worry, this plugin will help you.
django-autoslug
A short label for something, containing only letters, numbers, underscores or hyphens. They’re generally used in URLs. For example, in a typical blog entry URL:
null=True sets NULL (versus NOT NULL) on the column in your DB. Blank values for Django field types such as DateTimeField or ForeignKey will be stored as NULL in the DB.
blank determines whether the field will be required in forms. This includes the admin and your custom forms. If blank=True then the field will not be required, whereas if it’s False the field cannot be blank.
The combo of the two is so frequent because typically if you’re going to allow a field to be blank in your form, you’re going to also need your database to allow NULL values for that field. The exception is CharFields and TextFields, which in Django are never saved as NULL. Blank values are stored in the DB as an empty string ('').
A few examples:
models.DateTimeField(blank=True) # raises IntegrityError if blank
models.DateTimeField(null=True) # NULL allowed, but must be filled out in a form
Obviously, Those two options don’t make logical sense to use (though there might be a use case for null=True, blank=False if you want a field to always be required in forms, optional when dealing with an object through something like the shell.)
models.CharField(blank=True) # No problem, blank is stored as ''
models.CharField(null=True) # NULL allowed, but will never be set as NULL
CHAR and TEXT types are never saved as NULL by Django, so null=True is unnecessary. However, you can manually set one of these fields to None to force set it as NULL. If you have a scenario where that might be necessary, you should still include null=True.
CREATE TABLE Test(
id serial NOT NULL,"charNull" character varying(10),"charBlank" character varying(10) NOT NULL,"charNullBlank" character varying(10),"intNull" integer,"intBlank" integer NOT NULL,"intNullBlank" integer,"dateNull" timestamp with time zone,"dateBlank" timestamp with time zone NOT NULL,"dateNullBlank" timestamp with time zone,
CONSTRAINT Test_pkey PRIMARY KEY (id))
为MySQL 5.6创建的数据库字段是：
CREATE TABLE Test(`id` INT(11) NOT NULL AUTO_INCREMENT,`charNull` VARCHAR(10) NULL DEFAULT NULL,`charBlank` VARCHAR(10) NOT NULL,`charNullBlank` VARCHAR(10) NULL DEFAULT NULL,`intNull` INT(11) NULL DEFAULT NULL,`intBlank` INT(11) NOT NULL,`intNullBlank` INT(11) NULL DEFAULT NULL,`dateNull` DATETIME NULL DEFAULT NULL,`dateBlank` DATETIME NOT NULL,`dateNullBlank` DATETIME NULL DEFAULT NULL)
The database fields created for PostgreSQL 9.4 are :
CREATE TABLE Test (
id serial NOT NULL,
"charNull" character varying(10),
"charBlank" character varying(10) NOT NULL,
"charNullBlank" character varying(10),
"intNull" integer,
"intBlank" integer NOT NULL,
"intNullBlank" integer,
"dateNull" timestamp with time zone,
"dateBlank" timestamp with time zone NOT NULL,
"dateNullBlank" timestamp with time zone,
CONSTRAINT Test_pkey PRIMARY KEY (id)
)
The following arguments are available to all field types. All are optional.
null
Field.null
If True, Django will store empty values as NULL in the database. Default is False.
Avoid using null on string-based fields such as CharField and
TextField because empty string values will always be stored as empty
strings, not as NULL. If a string-based field has null=True, that
means it has two possible values for “no data”: NULL, and the empty
string. In most cases, it’s redundant to have two possible values for
“no data”; the Django convention is to use the empty string, not
NULL.
For both string-based and non-string-based fields, you will also need
to set blank=True if you wish to permit empty values in forms, as
the null parameter only affects database storage (see blank).
Note
When using the Oracle database backend, the value NULL will be stored to denote the empty string regardless of this attribute
blank
Field.blank
If True, the field is allowed to be blank. Default is False.
Note that this is different than null. null is purely
database-related, whereas blank is validation-related. If a field
has blank=True, form validation will allow entry of an empty value.
If a field has blank=False, the field will be required.
It’s crucial to understand that the options in a Django model field definition serve (at least) two purposes: defining the database tables, and defining the default format and validation of model forms. (I say “default” because the values can always be overridden by providing a custom form.) Some options affect the database, some options affect forms, and some affect both.
When it comes to null and blank, other answers have already made clear that the former affects the database table definition and the latter affects model validation. I think the distinction can be made even clearer by looking at use cases for all four possible configurations:
null=False, blank=False: This is the default configuration and means that the value is required in all circumstances.
null=True, blank=True: This means that the field is optional in all circumstances. (As noted below, though, this is not the recommended way to make string-based fields optional.)
null=False, blank=True: This means that the form doesn’t require a value but the database does. There are a number of use cases for this:
The most common use is for optional string-based fields. As noted in the documentation, the Django idiom is to use the empty string to indicate a missing value. If NULL was also allowed you would end up with two different ways to indicate a missing value.
Another common situation is that you want to calculate one field automatically based on the value of another (in your save() method, say). You don’t want the user to provide the value in a form (hence blank=True), but you do want the database to enforce that a value is always provided (null=False).
Another use is when you want to indicate that a ManyToManyField is optional. Because this field is implemented as a separate table rather than a database column, null is meaningless. The value of blank will still affect forms, though, controlling whether or not validation will succeed when there are no relations.
null=True, blank=False: This means that the form requires a value but the database doesn’t. This may be the most infrequently used configuration, but there are some use cases for it:
It’s perfectly reasonable to require your users to always include a value even if it’s not actually required by your business logic. After all, forms are only one way of adding and editing data. You may have code that is generating data which doesn’t need the same stringent validation that you want to require of a human editor.
Another use case that I’ve seen is when you have a ForeignKey for which you don’t wish to allow cascade deletion. That is, in normal use the relation should always be there (blank=False), but if the thing it points to happens to be deleted, you don’t want this object to be deleted too. In that case you can use null=True and on_delete=models.SET_NULL to implement a simple kind of soft deletion.
You may have your answer however till this day it’s difficult to judge whether to put null=True or blank=True or both to a field. I personally think it’s pretty useless and confusing to provide so many options to developers. Let the handle the nulls or blanks however they want.
Simply null=True defines database should accept NULL values, on other hand blank=True defines on form validation this field should accept blank values or not(If blank=True it accept form without a value in that field and blank=False[default value] on form validation it will show This field is required error.
Here, is the main difference of null=True and blank=True:
The default value of both null and blank is False. Both of these values work at field level i.e., whether we want to keep a field null or blank.
null=True will set the field’s value to NULL i.e., no data. It is basically for the databases column value.
date = models.DateTimeField(null=True)
blank=True determines whether the field will be required in forms. This includes the admin and your own custom forms.
title = models.CharField(blank=True) // title can be kept blank.
In the database ("") will be stored.
null=Trueblank=True This means that the field is optional in all circumstances.
epic = models.ForeignKey(null=True, blank=True)
// The exception is CharFields() and TextFields(), which in Django are never saved as NULL. Blank values a
Null: It is database-related. Defines if a given database column will accept null values or not.
Blank: It is validation-related. It will be used during forms validation, when calling form.is_valid().
That being said, it is perfectly fine to have a field with null=True and blank=False. Meaning on the database level the field can be NULL, but in the application level it is a required field.
Now, where most developers get it wrong: Defining null=True for string-based fields such as CharField and TextField. Avoid doing that. Otherwise, you will end up having two possible values for “no data”, that is: None and an empty string. Having two possible values for “no data” is redundant. The Django convention is to use the empty string, not NULL.
When we save anything in Django admin two steps validation happens, on Django level and on Database level. We can’t save text in a number field.
Database has data type NULL, it’s nothing. When Django creates columns in the database it specifies that they can’t be empty. And if you will try to save NULL you will get the database error.
Also on Django-Admin level, all fields are required by default, you can’t save blank field, Django will throw you an error.
So, if you want to save blank field you need to allow it on Django and Database level.
blank=True – will allow empty field in admin panel
null=True – will allow saving NULL to the database column.
There’s one point where null=True would be necessary even on a CharField or TextField and that is when the database has the unique flag set for the column.
In other words, if you’ve a unique Char/TextField in Django, you’ll need to use this:
For non-unique CharField or TextField, you’ll be better off skipping the null=True otherwise some fields will get set as NULL while others as “” , and you’ll have to check the field value for NULL everytime.
null is for database and blank is for fields validation that you want to show on user interface like textfield to get the last name of person.
If lastname=models.charfield (blank=true) it didnot ask user to enter last name as this is the optional field now.
If lastname=models.charfield (null=true) then it means that if this field doesnot get any value from user then it will store in database as an empty string ” “.
回答 13
模型中null = True和blank = True的含义还取决于如何在表单类中定义这些字段。
假设您定义了以下类：
classClient(models.Model):
name = models.CharField(max_length=100, blank=True)
address = models.CharField(max_length=100, blank=False)
The meaning of null=True and blank=True in the model also depends on how these fields were defined in the form class.
Suppose you have defined the following class:
class Client (models.Model):
name = models.CharField (max_length=100, blank=True)
address = models.CharField (max_length=100, blank=False)
If the form class has been defined like this:
class ClientForm (ModelForm):
class Meta:
model = Client
fields = ['name', 'address']
widgets = {
'name': forms.TextInput (attrs = {'class': 'form-control form-control-sm'}),
'address': forms.TextInput (attrs = {'class': 'form-control form-control-sm'})
}
Then, the ‘name’ field will not be mandatory (due to the blank=True in the model) and the ‘address’ field will be mandatory (due to the blank=False in the model).
However, if the ClientForm class has been defined like this:
class ClientForm (ModelForm):
class Meta:
model = Client
fields = ['name', 'address']
name = forms.CharField (
widget = forms.TextInput (attrs = {'class': 'form-control form-control-sm'}),
)
address = forms.CharField (
widget = forms.TextInput (attrs = {'class': 'form-control form-control-sm'}),
)
Then, both fields (‘name’ and ‘address’) will be mandatory, “since fields defined declaratively are left as-is” (https://docs.djangoproject.com/en/3.0/topics/forms/modelforms/), i.e. the default for the ‘required’ attribute of the form field is True and this will require that the fields ‘name’ and ‘address’ are filled, even if, in the model, the field has been set to blank=True.
+--------------------------------------------------------------------+|Purpose| null=True| blank =True||--------------------------|------------------|----------------------||Field can be empty in DB |Do this |Unaffected||--------------------------|------------------|----------------------||ModelForm(required field)|Unaffected| field not required ||--------------------------|------------------|----------------------||FormValidation|Unaffected| field not required ||--------------------------|------------------|----------------------|| on_delete=SET_NULL |Need this |Unaffected|+--------------------------------------------------------------------+
This table below demonstrates the main differences:
+--------------------------------------------------------------------+
| Purpose | null=True | blank = True |
|--------------------------|------------------|----------------------|
| Field can be empty in DB | Do this | Unaffected |
|--------------------------|------------------|----------------------|
| ModelForm(required field)| Unaffected | field not required |
|--------------------------|------------------|----------------------|
| Form Validation | Unaffected | field not required |
|--------------------------|------------------|----------------------|
| on_delete=SET_NULL | Need this | Unaffected |
+--------------------------------------------------------------------+
回答 16
在很简单的话，
空白不同于空值。
空是纯粹数据库相关的，而空白是验证相关的（在形式所需）。
如果是null=True，Django会的store empty values as NULL in the database。如果有一个字段blank=True，则将进行表单验证allow entry of an empty value。如果字段的空白为False，则将需要该字段。
null is purely database-related, whereas blank is validation-related(required in form).
If null=True, Django will store empty values as NULL in the database. If a field has blank=True, form validation will allow entry of an empty value. If a field has blank=False, the field will be required.
Maybe Q objects could be of help for this problem. I’ve never used them but it seems they can be negated and combined much like normal python expressions.
Update: I Just tried it out, it seems to work pretty well:
Your query appears to have a double negative, you want to exclude all rows where x is not 5, so in other words you want to include all rows where x IS 5. I believe this will do the trick.
To answer your specific question, there is no “not equal to” but that’s probably because django has both “filter” and “exclude” methods available so you can always just switch the logic round to get the desired result.
exact
iexact
contains
icontains
in
gt
gte
lt
lte
startswith
istartswith
endswith
iendswith
range
year
month
day
week_day
isnull
search
regex
iregex
I’m sure by combining these with the Q objects as Dave Vogt suggests and using filter() or exclude() as Jason Baker suggests you’ll get exactly what you need for just about any possible query.
While with the Models, you can filter with =, __gt, __gte, __lt, __lte, you cannot use ne, != or <>. However, you can achieve better filtering on using the Q object.
You can avoid chaining QuerySet.filter() and QuerySet.exlude(), and use this:
from django.db.models import Q
object_list = QuerySet.filter(~Q(field='not wanted'), field='wanted')
The Django issue tracker has the remarkable entry #5763,
titled “Queryset doesn’t have a “not equal” filter operator”.
It is remarkable because (as of April 2016) it was
“opened 9 years ago” (in the Django stone age),
“closed 4 years ago”, and
“last changed 5 months ago”.
Read through the discussion, it is interesting.
Basically, some people argue __ne should be added
while others say exclude() is clearer and hence __ne
should not be added.
(I agree with the former, because the latter argument is
roughly equivalent to saying Python should not have != because
it has == and not already…)
The last bit of code will exclude all objects where x!=5 and a is True. Try this:
results = Model.objects.filter(a=False, x=5)
Remember, the = sign in the above line is assigning False to the parameter a and the number 5 to the parameter x. It’s not checking for equality. Thus, there isn’t really any way to use the != symbol in a query call.
Django-model-values (disclosure: author) provides an implementation of the NotEqual lookup, as in this answer. It also provides syntactic support for it:
from model_values import F
Model.objects.exclude(F.x != 5, a=True)
