Hi, I've been thinking about my future production environment (still working locally though).
Considering how easy is to do db migrations with web2py, it could be "scary" if data is lost in a production system when migrations involve altering or deleting persistent data, e.g. deleting fields or changing a field type. Mistakes could be made by developers in the group, and once one realizes it the data is gone ! There's really no harm with the other types of migrations, e.g. defining more tables or fields, but only those that involve deleting persistent data. Does it make sense, as a matter of extra 'protection', to have a flag somewhere that provides this protection mechanism (e.g. "migrationCanDeleteData" or so, where the default is obviously False)?. In this case, if this flag is set to False and the developer tries to execute a "delete" migration (maybe by mistake), then just an error is raised, without harming the db data, in which case he either turns the flag on to complete the "delete" migration or realizes he was making a mistake. I know that migrate should be False by default in a production environment, but when required we usually intent to migrate to "add" (no harm) and not to "delete" (harm could happen), and therefore this extra level of protection. If I'm being too paranoid, then just ignore this :-) Take care, Carlos
