there are only two cases when migrations involve data loss: - you explicitly delete a Field from a table (are you worried this can be done accidentally?) - when you try convert a field type from "a" to "b" and they are incompatible (this is only a problem on mysql because every other database fail fail and rollback, mysql requires committing at each step and this can cause data corruption).
I guess we could add a safety switch for these cases? In favor? Opposed? On Nov 18, 6:09 pm, Carlos <[email protected]> wrote: > 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
