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
