Changes between Version 1 and Version 2 of Ticket #25456, comment 2


Ignore:
Timestamp:
Sep 25, 2015, 9:02:50 AM (9 years ago)
Author:
Frank

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #25456, comment 2

    v1 v2  
    22> Does the behavior change justify breaking backwards compatibility (silently changing the input value)? Perhaps so, considering that PostgreSQL (and its native IP address data type) won't let you store duplicate values. It reports "Key (ip)=(192.168.1.10) already exists." for the two addresses you proposed -- so is the proper normalization to remove the leading zero?
    33
    4 To start off, I do not really if you're advocating pro or con :-) But, I think the current situation is pretty bad. I mean, people can create models with addresses which they think have unique values. And in a sense this also goes against what you expect. You expect an generic ip address object to be evaluated as such, as an ip address, and not as a mere string value because it is stored as such. As far as I know, there is also not mention of this in the current documentation.
     4To start off, I do not really if you're advocating pro or con :-) But, I think the current situation is pretty bad. I mean, people can create models with addresses which they think have unique values. And in a sense this also goes against what you expect. You expect an generic ip address object to be evaluated as such, as an ip address, and not as a mere string value because it is stored as one. As far as I know, there is also not mention of this in the current documentation.
    55
    66So, I also don't think that preserving backwards compatibility preservation is doing anyone a service in this matter. This might leave people having unreliable data.
Back to Top