Nowhere else is [Ii]s_home_team referenced.
I had to move on, so I deleted the table and recreated it.
On Thursday, September 13, 2012 2:01:51 PM UTC-6, Marin Pranjić wrote:
>
> I don't think KeyError is related to migrations. I am not sure.
> Can you give us error traceback?
>
> On Thu, Sep 13, 2012 at 7:20 PM, MichaelF <mjf...@gmail.com
> <javascript:>>wrote:
>
>> I don't know where the lower case is_home_team is coming from. In the
>> entire app dir it appears only in the error pages.
>>
>> The 'migrate = true, fake_migrate = true' yields the same error.
>>
>>
>> On Thursday, September 13, 2012 11:14:32 AM UTC-6, Marin Pranjić wrote:
>>
>>> What about the case
>>> Is_home_team / is_home_team?
>>>
>>> On Sep 13, 2012 6:37 PM, "MichaelF" <mjf...@gmail.com> wrote:
>>>
>>> I have a field ('Is_home_team') that was defined as 'boolean', and I
>>> changed it to 'integer'. The migrate failed (I'm using MySQL).
>>>
>>> I then invoked the following on the table def that defines Is_home_team:
>>> migrate = False, fake_migrate = True
>>>
>>> I also altered the underlying MySQL table to change the field from
>>> char(1) to integer, and modified the data.
>>>
>>> I then ran the app again, and everything worked. So I took out the
>>> 'migrate = False, fake_migrate = True', re-ran the app, and got the error
>>> again:
>>> <type 'exceptions.KeyError'> 'is_home_team'
>>> I thought that running the fake_migrate would rebuild according to the
>>> definition, etc.
>>>
>>> No other tables refer to that field.
>>>
>>> Before I do a fake_migrate_all, any thoughts?
>>>
>>> --
>>>
>>>
>>>
>>>
>>> --
>>
>>
>>
>>
>
>
--
