I'm worried about losing control over the db migration process. Using
MySql it is fairly common for the migration process to go wrong, as MySql
doesn't do will with adding and deleting multiple columns. I often need to
drop a few tables, delete the corresponding file in 'databases' and then
force recreating the tables. It's easier than manually editing the tables
in a MySql session and doing a "fake" migrate.
Will this change make it harder to recover from migrations that don't go
well, turning it into an "all or nothing" approach? That would create some
difficulty for me unless I have good workarounds.
Joe
On Sunday, September 2, 2018 at 11:08:50 AM UTC-7, Massimo Di Pierro wrote:
>
> We you may know web2py has the ability to store table metadata in DB:
>
> from gluon.dal import InDBMigrator
> db = DAL(myconf.get('db.uri'), adapter_args=dict(migrator=InDBMigrator))
>
> This is better for scalability as there is no filsystem IO.
>
> How do people feel with the following:
> - make the above the default behavior (no more metadata/*.table)
> - eliminate logging in databases/sql.log as use log.info instead
> - make migration always on on localhost and appadmin and always off
> otherwise
> - create a script and an appadmin endpoint for fake_migration (partial
> database repair)
>
> This can be done with a change to the welcome app in a backward compatible
> manner.
> Hardest part is update the docs.
>
> Massimo
>
--
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.com/p/web2py/issues/list (Report Issues)
---
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/d/optout.
