#5622: Empty ipaddress raises an error (invalid input syntax for type inet: "")
-----------------------------+------------------------------------
Reporter: anonymous | Owner: erikr
Type: Bug | Status: closed
Component: Forms | Version: master
Severity: Normal | Resolution: wontfix
Keywords: sprintdec01 | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-----------------------------+------------------------------------
Changes (by erikr):
* status: assigned => closed
* resolution: => wontfix
Comment:
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
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/5622#comment:61>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
