Issue 81 in django-evolution: field type change with same db_type should not require any evolution
codesite...@google.com
evolution
http://code.google.com/p/django-evolution/issues/detail?id=81
Comment #2 by daevaorn:
Just now I faced the same problem with custom subclassed field. Thanks for
the patch.
I'll try it.
--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings
codesite...@google.com
evolution
http://code.google.com/p/django-evolution/issues/detail?id=81
Comment #3 by chipx86:
This doesn't seem to work in all cases. Try going from a URLField to a
CharField. In
my tests, I end up getting a field_type error still, and if I do some
debugging, I
see that old_value().db_type() is "varchar(200)" while
new_value().db_type() is
"varchar(None)".
I have a patch that allows ChangeField to accept a new field_type, which is
a more
manual version of this change. I would rather see Django Evolution be
smarter about
this, so I'd like to see your patch go in, if it works in the above case.
codesite...@google.com
evolution
http://code.google.com/p/django-evolution/issues/detail?id=81
Comment #4 by chipx86:
Okay, looking into this more, there's a few problems.
First, while this works for simple types like an integer field, it'll never
work for
things like a CharField. The reason for this is that db_type() not only
returns the
generic type but rather the specific type with length. For example,
varchar(200) vs
varchar(255).
There's a couple things that could be done, such as chopping off everything
after the
"(", but I don't like that much.
I looked into using get_internal_type(), but I'm not sure this is much
better. It
wouldn't allow for going between, say, a CharField and a TextField.
Issue attribute updates:
Status: Accepted
Owner: chipx86
codesite...@google.com
evolution
http://code.google.com/p/django-evolution/issues/detail?id=81
Comment #5 by chipx86:
Actually, maybe get_internal_type is really what we want for the
auto-determination.
Anything more complicated probably needs another more specific method
entirely.
codesite...@google.com
evolution
http://code.google.com/p/django-evolution/issues/detail?id=81
Comment #6 by chipx86:
Alright, I went ahead and committed a fix that works similarly to yours but
with the
exception of using get_internal_type() (which should work better in the
cases we're
trying to fix, and is recommended for checking type compatibility). This
also fixes
an issue with the original patch where we were breaking out of the property
loop,
when we really should have continued on to the next property.
This was committed as r164. Thanks!
Issue attribute updates:
Status: Fixed
codesite...@google.com
evolution
http://code.google.com/p/django-evolution/issues/detail?id=81
Comment #7 by carl.j.meyer:
In the CharField cases where the length differs, don't we want an evolution
to occur?
Otherwise the database schema will be left in a state inconsistent with
the models,
because the VARCHAR will be the wrong length.
This is why I used db_type, because it represents exactly what is being
created at
the database level - and it seems to me that if this differs, we shouldn't
paper over
the difference.
codesite...@google.com
evolution
http://code.google.com/p/django-evolution/issues/detail?id=81
Comment #8 by chipx86:
That's why it's important to continue instead of break in that loop. The
max_length
still changes, and it's not necessary to rely on db_type for this.
In the example of going from a URLField with a default max_length of 200 to
a
CharField with a specified max_length of 256, the database signature will
show that
both field_type and max_length changed. So a mutation would still have to
be written
to cover this. Now, if you specified a CharField with a max_length matching
URLField,
you wouldn't, because all that would have changed was the field_type.
codesite...@google.com
evolution
http://code.google.com/p/django-evolution/issues/detail?id=81
Comment #9 by carl.j.meyer:
Ah, of course, makes sense. Thanks for fixing and committing the patch,
and for the
education :-)
codesite...@google.com
Comment #10 on issue 81 by lwcyphr: field type change with same db_type
http://code.google.com/p/django-evolution/issues/detail?id=81
I've run across this issue when modifying a field from CharField to
SlugField and the
current version (166) which has the previous patch applied does not work
because the
internal type is different. I've attached another diff where I'm using an
approach
previously commented but discarded. This worked fine.
Attachments:
issue81.diff 1.4 KB