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 <jdillwo...@gmail.com> 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
