Such a simple question, but can't seem to find anything in the documentation about it.
For example, can integers be negative?
There is none. Any integer is valid. Negative is definitely fine. But the IntegerField is not limited by default. #16747 closed Bug (wontfix) IntegerField could validate too large numbers to work with PostgreSQL and MySQL be default was a request to fix this, but it was denied.
Keep in mind that an IntegerField is not necessarily connected to a particular database field. It usually is, in which case the recommendation is to add max_value and min_value to match your database field requirements.
If you're talking about models.IntegerField then there is indeed a range for that and it is mentioned in the documentation.
An integer. Values from -2147483648 to 2147483647 are safe in all
databases supported by Django.
It uses MinValueValidator and MaxValueValidator to validate the input
based on the values that the default database supports.
If you're talking about forms.IntegerField, then the only way to validate it is to pass a parameter of max_value and min_value for that.
Validates that the given value is an integer. Uses MaxValueValidator
and MinValueValidator if max_value and min_value are provided.
Related
I have a database filled with values for first_name. I also made a form, which calls for an input of first_name. How can i give the user suggestions as they type of names that are already in the database?
Also, if i have someone entering 2 in one integerfield, and a 3 in another integerfield, how can i autocompute the product and show it in real-time?
The package https://github.com/yourlabs/django-autocomplete-light seems to be what you're looking for.
It allows the end user to type some characters, after which it will be autocompleted/suggested from what's already in the DB.
For autocomputing the two intergerfields, I'd go for client-side (Javascript).
Django 1.8 now has some problem detection for models, which is nice. However, for one warning that it is giving me, I understand the problem, but I don't understand how the hint that it is giving me is any better.
This is my (bad) model field:
my_date = DateField(default=datetime.now())
and it's easy to see why that's bad. But this is the hint it's giving me:
MyMoel.my_date: (fields.W161) Fixed default value provided.
HINT: It seems you set a fixed date / time / datetime value as default for this field. This may not be what you want. If you want to have the current date as default, use `django.utils.timezone.now`
So, it says to use timezone.now, but how is that any better than datetime.now? They're both "fixed default" values... timezone.now just returns a datetime instance, which is a fixed value...
I suspect that it actually wants me to insert some sort of flag that says "use timezone.now later". But that's not what the hint says... so what is that flag?
The function datetime.now() is currently executed as soon as your code is imported, i.e. when you (re)start your server. All subsequent model instances will have the same value.
Instead, you should pass a callable function to default, that is executed each time a model instance needs a default value. The hint wants to convey that you should literally use DateField(default=django.utils.timezone.now) without the parentheses.
The message is slightly misleading, but Django doesn't know whether you used datetime.now() or django.utils.timezone.now().
The difference between timezone.now() and datetime.now() has been explained well in the above answers.
However, the reason you're getting an error is because you are running the function which will set the default time as the time while applying migrations to the database.
All you had to do was use,
my_date = DateField(default=datetime.now)
instead of
my_date = DateField(default=datetime.now())
In the above method, the timezone.now function will be called while inserting/ modifying an Object.
In my models I need to store a mobile number in the following format 447182716281. What field should I use? Does Django have anything to support this?
example
mobile = models.IntegerField(max_length=12)
Phone numbers must be CharFields. Integer field will not preserve leading 0, +, and spacing.
I think is a interesting question since it really depends on the problem modeling, CharField works fine, but have a look at this:
ORM tricks
There is a regex field in form validation. In model use just CharField.
On using models.IntegerField(default=0)
for larger number it gives error
Ensure this value is less than or equal to 2147483647.
So better way to use would be.
BigIntegerField
A 64-bit integer, much like an IntegerField except that it is guaranteed to fit numbers from -9223372036854775808 to 9223372036854775807. The default form widget for this field is a TextInput.
with PostgreSQL IntegerField is not working properly so it's better to use CharField with Django.
Number=models.CharField(max_length=12)
I have an object with a DecimalField value of 5.60. I'm making a query:
Mdl.objects.get(speed__iexact="5.60")
This will return the correct result. But this will not:
Mdl.objects.get(speed__iexact="5.6")
Is there a way to automatically reconcile this inconsistency? The filter value is user provided, so I want to be sure that a user typing 5.6 can find the object.
iexact does an case-insensitive equality check, which is normally used for strings. For decimals with two decimal places, the Django database backend will probably store "5.60" as string for a DecimalField, so iexact-comparison with that will work because the strings are equal. But as you want to compare numbers, not strings, you should just use the normal equality operator.
from decimal import Decimal
Mdl.objects.get(speed=Decimal("5.6"))
Don't use strings, instead use the Python-builtin Decimal type. When retrieving model instances with Django, you will get instances of that type anyway, so you should also assign this type in order to be consistent.
"What is the biggest integer the model field that this application instance can handle?"
We have sys.maxint, but I'm looking for the database+model instance. We have the IntegerField, the SmallIntegerField, the PositiveSmallIntegerField, and a couple of others beside. They could all vary between each other and each database type.
I found the "IntegerRangeField" custom field example here on stackoverflow. Might have to use that, and guess the lowest common denominator? Or rethink the design I suppose.
Is there an easy way to work out the biggest integer an IntegerField, or its variants, can cope with?
It depends on your database backend.
Use ./manage.py sql your_app_name to check generated types for your DB-columns, and look through your database documentation for type ranges.
For MySQL: http://dev.mysql.com/doc/refman/5.1/en/numeric-types.html
For PostgreSQL: http://www.postgresql.org/docs/8.1/static/datatype.html#DATATYPE-TABLE
Can't be easily done. Just set a constant and use that.
MAX_SMALL_INT = 32767
position = models.PositiveSmallIntegerField(default=MAX_SMALL_INT)