Thanks Yarko. That's helpful. Part of my problem is that the ultimate target for my work is a PDA (Nokia N8x0) but I'm developing on a Macbook because I need to have the web2py tree including my app under SVN (it's a piece of a much larger software effort). I'm also not leaving the web2py server running all the time. Restarts happen several times daily on either platform. FWIW, I'm using the default SQLite db since, comparatively speaking, very little data is involved. I tried the explicit migration names, but it didn't seem to make any difference. It sounds like this is a limitation I'll just need to live with -- at least for now. Not a huge deal because there's so much to like about the web2py framework.
Mike On Jun 30, 6:23 pm, Yarko Tymciurak <yark...@gmail.com> wrote: > table migrations should work as described - if you are developing, and > changed databases, or started a new db (e.g. restarted) then what you are > seeing is web2py seeing a conflict between it's concept of history for a > table on a particular db, and what an instance has.... > > This is in your benefit. > > Rather than "migrate=False" another strategy you can use is to not use > automatic table names for web2py's files, but rather define your own. > > For example - db.define_table( 'person', ........ , > migrate='sqlite.person.table') > > which you could switch to "...... migrate=myslq-myrev432.person.table') # > revs for when you completely restart w/ a new db... > > Get the idea? > > Migrate False just makes the files web2py use ignored (so those conflicts > between what might have been created in the db, and what web2py thinks is > there).... this is another strategy. > > You can, for now, also clear out all the *.table files from your app's > databases directory (if you put them somewhere else, you can put them back > if you change your mind) > > Hope this sheds a little more light. > > On Tue, Jun 30, 2009 at 4:07 PM, MikeEllis <michael.f.el...@gmail.com>wrote: > > > > > Thanks Fran, that makes it much clearer. It would be nice if > > migrate=True worked as described in the manual, but I can live with > > migrate=False for the time being. Just have to make sure to get my > > table designs correct from the start (LOL). > > Cheers, > > Mike > > > On Jun 30, 4:52 pm, Fran <francisb...@googlemail.com> wrote: > > > On Jun 30, 4:57 pm, MikeEllis <michael.f.el...@gmail.com> wrote: > > > > > doesn't migrate=False prevent me from altering the > > > > table's structure within a running instance of web2py? > > > > Mostly correct - migrate=False means that Web2Py doesn't try to create > > > the Table, but assumes this exists already. > > > > > am I misunderstanding > > > > what migrate=False does? I'm assuming it means the table will be > > > > dropped with all its data and a new one will be created? > > > > No it won't drop the table/data - migrate=False simply means that only > > > Table Data not Structure is editable. > > > > F > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web2py Web Framework" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
