It is. fixing it.
On Sep 23, 12:07 am, Jeremy Dillworth <[email protected]> wrote: > There's just one more issue I wanted to raise. It didn't hit me until > I was > describing the situation to a non-technical friend. When the value is > blank, > the error message doesn't say the value is blank, it says > "value already in database". I wasted some time wondering where this > mysterious blank was in my database and it wasn't until I actually > read the > source at gluon/validators.py that I found out what was going on. > > Isn't that a usability problem? I could understand IS_DATE > telling me that a blank value is not a valid date, but I think > telling the user that a blank is in the database when it really > isn't is pretty confusing. > > Jeremy > > On Sep 22, 9:44 am, mdipierro <[email protected]> wrote: > > > Because it was undocumented I was allowed to change it. I changed it > > because I think the previous behavour was a bug. Allowing IS_NOT_IN_DB > > to validate as '' is like saying that '' is allowed in the referenced > > database field and (while technically possible) it is not a good idea > > to allow that. causes all kind of headaches. > > > Normally if people insert space in a field that is supposed to be > > unique they mean > > > IS_EMPTY_OR(IS_NOT_IN_DB(..)) > > > Your fix is the correct one and I apologize for the trouble. Bug fixes > > that change behaviour are very rare. > > > Massimo > > > On Sep 22, 1:23 am, Jeremy Dillworth <[email protected]> wrote: > > > > Before I start complaining, thanks for the free software. > > > > I just ran into some trouble with IS_NOT_IN_DB in a form. Change set > > > 5a1355b3d0 made this return false for blank values. I don't know what > > > the motivation was for this change, but it broke my app. > > > > My app is creating a custom form by passing a list of fields to > > > SQLFORM.factory. The field in question was used to create a child > > > record on a related table. I used my own code to create rows from the > > > SQLFORM and whenever this field was blank, I simply skipped that > > > insert. > > > > I did find a fix, I wrapped my IS_NOT_IN_DB calls with IS_EMPTY_OR(). > > > > Isn't this a backward incompatible change? > > > > I can't find where IS_NOT_IN_DB's behavior with blanks is documented > > > either way, so shouldn't it have been left alone? > > > > Is there some changelog I missed? > > > > Thanks > > > > Jeremy > >
