Empty ipaddress raises an error (invalid input syntax for type inet: "")

[anonymous]

That is - the admin interface raises an exception when saving an object with an empty IPAddressField

[James Bennett]

Sounds like you've perhaps set blank=True on the field and forgotten to supply a fallback value elsewhere in your code. Please ask -- with detailed information -- on the django-users mailing list.

[anonymous]

Replying to ubernostrum:

Sounds like you've perhaps set blank=True on the field and forgotten to supply a fallback value elsewhere in your code. Please ask -- with detailed information -- on the django-users mailing list.

the model definition has this field:

reported_ip = models.IPAddressField(blank=True, null=True, default=None)

The problem is that when i edit an object containing this field, in the admin site, i want to be able to leave this field empty. I'm only working with models definition and I don't have other code.

[Thomas Kerpe]

I can not reproduce this with newforms-admin [6783].

class Host(models.Model):
    name = models.CharField(maxlength=100)
    ip = models.IPAddressField(blank=True, null=True, default=None)

Create, Update, Delete.
Maybe the Database-Field is "NOT NULL"?

[anonymous]

It's an Postgresql issue.
When using postgresql_psycopg2 the described error will occour.
Not in sqlite3!

[Thomas Kerpe]

Replying to anonymous:

It's an Postgresql issue.
When using postgresql_psycopg2 the described error will occour.
Not in sqlite3!

That was me.

[Thomas Kerpe]

Postgresql inet type don't allow empty inet fields. Null is OK.
Should an empty string in the admin be converted to a NULL value in the DB?

​http://www.postgresql.org/docs/7.4/interactive/datatype-net-types.html#DATATYPE-INET

[Thomas Kerpe]

See also #4684

[Thomas Kerpe]

This Problem applies to whole newforms. In oldforms this is AFAIK handled by html2python.

Maybe more such Bugs?

[Brian Rosner]

This looks to be a bug in newforms and not only newforms-admin. Moving it out of newforms-admin.

[Thomas Kerpe]

Alternative Patch at newforms-level

[Thomas Kerpe]

The alternative Patch solves the same issue as the first one.

IMHO it's a issue at the database layer (the data representation in the database) so I would tend to fix such things at db-layer.

[Chris Beaven]

Needs some tests to show the problem being solved. On the surface, it looks like this should work, since IPAddressField has empty_strings_allowed = False

I concur that it should be fixed at the db level.

[Matias Surdi]

I've just found this issue too with an IPAddressField. The patch 5622.1.patch seems to solve the problem correctly, at least for me.

Will this be merged into trunk at some point?

[Chris Beaven]

Msurdi - which database backend are you using?

Would you like to take a shot at writing some tests - that'll speed up the chance of it getting merged.

[Matias Surdi]

I'm using PostgresQL 8.3

And I'm working on the fix and the tests.....

[Matias Surdi]

Fix and Tests

[Matias Surdi]

I've just attached the fix and the tests.

Please, let me know if you find something is wrong to fix it. I'd love to get this into trunk before 1.1.

Many thanks.

[Matias Surdi]

Hi guys.... I'm hitting this bug/problem again..... and it seems that the original patch is not present on Trunk.

Is it possible that somebody forgot to include the patch?

Thanks...

[Alex Gaynor]

Based on the fact that this ticket has never been closed and marked as fixed, yes I would say this patch isn't in trunk.

[Tyler Brownell]

I'm still having this issue using the latest trunk. Is there a reason this has not been committed? Is there anything anyone can do to move this forward?

[imbaczek]

what's the status on this issue? i've just hit it and it's a bit baffling.

[Stephane Raimbault]

Updated to trunk (> Django 1.2.1)

[Stephane Raimbault]

Could you have a look at this patch (opened since 3 years), please?

[Łukasz Rekucki]

There's probably more chance for review is this is marked as accepted (as it's obviously a bug). If someone really needs this in trunk, you can always try django-developers and make a deal with one of core devs.

[jfunk]

Version that does not break BooleanField

[anonymous]

Same problem as I've duplicated ​here by mistake. No milestone set in 3 years? This looks promising :)

[Chris Beaven]

How about we slate it for 1.3 then. Get some discussion going in django-dev group to get things rolling.

[Stephane Raimbault]

This ticket has a 1.3 milestone...

Smiley, have you received feedback on this bug from django-dev?

[Łukasz Rekucki]

IMHO, Current patch fixes the problem on the wrong level (It shows however, that the validation part should be moved to the model field, now that we have model validation). forms.IPAddressField should return a string that's a valid IPv4 address, fail or return None (not "", like it's documented right now).

[Jacob]

Milestone 1.3 deleted

[rihad]

In the mean time, we can use models.GenericIPAddressField. It's still Postgres type inet, and it seems to just work.

[anonymous]

models.GenericIPAddressField is not in 1.2

[anonymous]

is there a way to overwrite django.db.backends.postgresql.creation?

[anonymous]

this is very ugly but it worked for me:

class IPAddressField(models.IPAddressField):

max_length = 15
def get_internal_type(self):

return "CharField"

[anonymous]

Will a decision be made on how to fix this bug? I vote for a null=True, convert empty strings to null solution, for what it's worth.

[diepes]

Bumped into same problem using sqlight3 in django 1.4

For me the solution is default="0.0.0.0"

[Ashutosh Dwivedi]

@diepes Just check with django (1, 5, 0, 'alpha', 0) for sqlite3 not able to reproduce it there.

[Ashutosh Dwivedi]

can we really use empty_strings_allowed? from what i can see the only use of empty_strings_allowed is to check

      if (self.empty_strings_allowed and
              connection.features.interprets_empty_strings_as_nulls):
              self.null = True

which is the case for oracle.We can have blank values for integer field in the db even if empty_strings_allowed is set to false for it.

[Ashutosh Dwivedi]

can we use the NullableWidget as being discussed here https://code.djangoproject.com/ticket/4136

[Ashutosh Dwivedi]

I think this can be merged with #4136

[kace]

For users facing this irritating issue, there is a quick, effective work-around (based on one of toke's patches (thank you)). Put this into "models.py":

class IPAddressFieldNullable(models.IPAddressField) :
    def get_db_prep_save(self, value):
        return value or None

Then change your IP attribute to use this modified field. E.g.:

-   someip = models.IPAddressField(blank=True, null=True )
+   someip = IPAddressFieldNullable(blank=True, null=True )

[peterkmurphy@…]

Thanks, kace - but this has added a new error with Mezzanine. (Mind you, it's with a PostGIS enabled database as well.)

TypeError at /admin/eventjunkie/ejeventcomment/add/

get_db_prep_save() got an unexpected keyword argument 'connection'

Request Method: 	POST
Request URL: 	http://eventjunkie.pkmurphy.com.au/admin/eventjunkie/ejeventcomment/add/
Django Version: 	1.4.1
Exception Type: 	TypeError
Exception Value: 	

get_db_prep_save() got an unexpected keyword argument 'connection'

Exception Location: 	/home/daoosaigon/envs/mezz64nosite/lib/python2.7/site-packages/django/db/models/sql/compiler.py in as_sql, line 872
Python Executable: 	/home/daoosaigon/envs/mezz64nosite/bin/python

[kace <kace7@…>]

peterk, all I can tell you is it works very well for me. Probably, you have to point the finger at Mezzanine. (... In any case, this really isn't right place to go into troubleshooting details!) Best of luck.

[Anton Agestam]

Replying to kace:

For users facing this irritating issue, there is a quick, effective work-around (based on one of toke's patches (thank you)). Put this into "models.py":

class IPAddressFieldNullable(models.IPAddressField) :
    def get_db_prep_save(self, value):
        return value or None

Then change your IP attribute to use this modified field. E.g.:

-   someip = models.IPAddressField(blank=True, null=True )
+   someip = IPAddressFieldNullable(blank=True, null=True )

Thanks for quick fix, confirmed working. Will this ever be fixed?

[Mike Fogel]

Extending the 'blank' kwarg as described here https://code.djangoproject.com/ticket/4136#comment:24 would cover this case as well by doing:

some_ip = models.IPAddressField(blank=models.SET_NULL, null=True)

[Claude Paroz]

#6233 reported this issue related to fixtures deserialization.

[Sasha Romijn]

I can confirm this issue exists with IPAddressField. The problem is that the both IPAddressField and GenericIPAddressField are backed by string types on most databases, but by INET on PostgreSQL. That explains why storing a blank value works with most databases, but breaks with PostgreSQL.

This issue does not affect GenericIPAddressField, because in get_db_prep_value, it does: return value or None - as kace already suggested. An empty string evaluates to false, the value returned is None, therefore it will be stored as NULL in the database - a valid value for PostgreSQL's INET.

The obvious fix here is to use the same get_db_prep_value in IPAddressField. However, this breaks backwards compatibility. Anyone who is running a database other than PostgreSQL, will currently have these blank values stored as an empty string. After this fix, they will suddenly be stored as NULL in all databases. This means existing queries may also break - querying for an empty string is different from querying for NULL.

The simple workaround is to use GenericIPAddressField in all cases, which can be made to behave similar to IPAddressField, as you can control the protocols it will accept. Considering that fixing this will break backwards compatibility for some people, and a drop-in workaround is available, I think we should not resolve the issue. Therefore, I am closing the ticket as wontfix. Overall, maybe we should even deprecate IPAddressField, as it can be completely replaced by GenericIPAddressField.

Regarding the failure peterkmurphy saw with mezzanine, the issue is not caused by mezzanine - it's the incorrect signature for get_db_prep_value.
The correct implementation would be:

    def get_db_prep_value(self, value, connection, prepared=False):
        if not prepared:
            value = self.get_prep_value(value)
        return value or None

[Aymeric Augustin]

erik's analysis is sound, I confirm the wontfix.