Looks like the book is wrong. IS_IN_SET automatically converts the integer values in the set to strings, so if IS_INT_IN_RANGE is used first, it will pass an integer to IS_IN_SET, which will fail. As far as I can tell, everything works fine without using IS_INT_IN_RANGE at all, using SQLFORM or SQLFORM.factory. I don't think you even have to cast to int before doing the manual db insert. Try just using IS_IN_SET as you have, and just do the insert without any transformation -- does that work?
Anthony On Tue, Dec 6, 2011 at 4:40 PM, Vinicius Assef <[email protected]>wrote: > On Tue, Dec 6, 2011 at 7:04 PM, Anthony Bastardi <[email protected]> > wrote: > > What happens if you reverse the order of the validators: > > > > Mytable.payday.requires = [ > > IS_IN_SET(G_DAYS_AVAILABLE, error_message="Choose one day"), > > IS_INT_IN_RANGE(0,31)] > > Anthony, the book says if I want an integer field, I must put > IS_INT_IN_RANGE() before IS_IN_SET(). Otherwise, the content will be a > string. > > > > Or what happens if you leave out the IS_INT_IN_RANGE validator > altogether? > > Actually, I solved this problem with just IS_IN_SET(). I made a > typecasting before inserting data in database, because I'm using > SQLFORM.factory(). > > But, if I was using just SQLFORM, this error could not occur, right? > > Or it is a bug and need a correction. Or the book needs to be updated, > to strip out that part about the 2 validators to get an int field. > > -- > Vinicius Assef. >
