mmmm..... no.... something is wrong here.... Get a copy of WingIDE, step through to that error you are seeing - instpect things; either you have an error somewhere (which would be good to understand for you), or you have potentially found something (which I'd like to see)....
I suggest trying the *3.2.0b2 <http://www.wingware.com/downloads> *beta version of WingIDE (look towarrds the bottom of a particular listing - e.g. Professional) Thanks, - Yarko On Tue, Jun 30, 2009 at 6:33 PM, MikeEllis <michael.f.el...@gmail.com>wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
