That's not a justified reason. If I have a table with a column that has zero nulls in it, it is perfectly reasonable for me to expect to be able to add a not-null constraint after the fact. If web2py is dealing with this migration, it should at least attempt to do it correctly. It should only fail if the table already contains nulls in that column. Otherwise, it should work. Web2py tries to circumvent a migration issue, and trips-on-itself because of bad-design of order-of-operations. It should "temporarily" add a default-constraint to the temp-field, to allow the setting of the not-null constraint while the new column is empty, THEN set the not-null constraint, THEN copy the data, and THEN remove the default-constraint in case the developer did not explicitly ask for it also. This way, the legitimate-expectation could be fulfilled, and only the non-legitimate expectation fail (in case there are "really" already nulls in that column)
-- --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
