Ok. This is a problem only with Mysql? with ProgreSQL too?
Eduardo
El jueves, 5 de julio de 2012 22:40:56 UTC-4, Massimo Di Pierro escribió:
It is not like that field level migrations do not work. They work if, for
example you change a field type. They do not work it you change an
What I said was wrong. I had to look at the source code and what it does is
a bit more complex.
If the SQL used for the original field definition is different than the SQL
that would be used to define the field in the current model:
If sqlite: ignore it
elif the field type is 'reference',
web2py does not know how to migrate when you add a unique=True because
existing data may break the contraint. You have some option:
1) if there is no data in db, comment the line in model (it will be
dropped), then add it again with the unique constraint
2) if you have data, add the unique
I believe that field level migrations do not work with MySQL. I get around
this by removing the column, saving, run the app to force migration, and
then add the field back the way I want it. I know this causes you to lose
the data in that column, but I only do this in my test environment and
Thanks for that. I didn't realize field-level migrations don't work with
MySQL. I'm no expert on web2py migrations (or even web2py!); is it just
with MySQL that it has these problems?
I suppose I could do this as an alternative to what you suggested: In
web2py add a new field with unique, then
It is not like that field level migrations do not work. They work if, for
example you change a field type. They do not work it you change an
attribute (unique, notnull).
On Thursday, 5 July 2012 16:40:42 UTC-5, MichaelF wrote:
Thanks for that. I didn't realize field-level migrations don't
6 matches
Mail list logo
