I agree with massimo about using web2py's migration features where possible. Unfortunately there are some migrations that web2py just cannot do if there is data in the table (at least that was true in postgres a while ago). Such things include making a previous nullable field not nullable, and i think adding unique qualifiers to an existing field. i have not looked at the latest versions of the code to see if they do those migrations better or not, as i have gotten used to my manual management of tables. i know it had to do with web2py making a copy of existing data into a temp table with the new schema rather than the old schema and not being able to specify transformations for existing data (a decently difficult problem to solve i suspect....and i'd rather see the crew working on things like cube2py than such mundane migrations)
cfh On Jul 21, 3:07 am, mdipierro <mdipie...@cs.depaul.edu> wrote: > It is better to always use web2py but remember to use (default) > migrate=True every time you edit the db. > You may also want to keep a backup of your database/*.tables > > On Jul 21, 4:54 am, Paul Gerrard <p...@gerrardconsulting.com> wrote: > > > An updqate. > > > I read the manual 6.4 on Migrations. I've added a migrate='tablename' > > aramter to the table definition call. It seems to work. > > > So I guess I've disconnected the table definition from the Web2py > > table history. So far so good. > > > So I have a more general point. > > > "Is it 'better' to manage database designs using the Web2py model or > > better to manage the database using the DB utilities and keep the > > model in sync?" I understand the web2py model route ought to be > > better, but this is the second time I've lots hours messing around > > with out of sync database and models.
