Hi Massimo,
I've switched to trunk and yes the fields are now being created as expected.
As a suggestion could the auto migration have an extra check added to
ensure that "upload" columns - if on non filesystem environments like GAE -
alway create the equivalent _blob column?
Thankfully even though the original columns have been dropped from the
schema (along with my data) it's only currently running on my on local
development machine so the loss isn't too much of a problem as I can
recreate the data again.
Thanks again for your fast response and fix.
Kind regards,
Matt
On Wednesday, September 12, 2012 2:28:09 AM UTC+12, Massimo Di Pierro wrote:
>
> I found the web2py bug that caused this problem. It was an indentation
> issue. Took the occasion to rewrite the logic a little better.
>
> Can you please check this works now? You should be able to update to trunk
> and your missing fields should re-appear (they will be hidden,
> writable=False, readable=False) but web2py should be able to use them as
> intended.
>
> Please let me know asap.
>
> Massimo
>
> On Tuesday, 11 September 2012 03:44:46 UTC-5, Matt wrote:
>>
>> Hi there,
>>
>> First off thanks for all of the fantastic work putting 2.0 together.
>> Looking forward to trying the new features.
>>
>> I've just upgraded from 1.99.7 -> 2.0.8 and I've discovered a serious bug
>> which has resulted in the loss of my data.
>>
>> [I'm using both GAE with CloudSQL and dal(migrate_enabled = True)]
>>
>> The automatically created image_blob references for GAE fields like:
>>
>> Field('image', 'upload', required = True, length = 100)
>>
>> Have vanished and with them the data contained in the image_blob fields.
>>
>> It seems to have happened fairly randomly i.e. some tables are fine but
>> others are affected. Out of about 6 tables using uploads only two still
>> have the extra blob columns.
>>
>> I've had some of these table definitions around for a long time and they
>> haven't changed. Whereas some others have been edited more recently.
>>
>> Any help or suggestions would be appreciated. Happy to give mere
>> information if possible.
>>
>> Thanks in advance,
>> Matt
>>
>> BTW: Also had this problem occur prior to the above:
>>
>> self.db.executesql("CREATE TABLE IF NOT EXISTS web2py_filesystem (path
>> VARCHAR(512), content LONGTEXT, PRIMARY KEY(path) ) ENGINE=InnoDB;")
>> File "/Projects/www/gluon/dal.py", line 7234, in executesql
>> adapter.execute(query)
>> File "/Projects/www/gluon/dal.py", line 4002, in execute
>> return self.log_execute(a.decode('utf8'))
>> File "/Projects/www/gluon/dal.py", line 1653, in log_execute
>> ret = self.cursor.execute(*a, **b)
>> File "/Library/Python/2.7/site-packages/MySQLdb/cursors.py", line 174,
>> in execute
>> File "/Library/Python/2.7/site-packages/MySQLdb/connections.py", line
>> 36, in defaulterrorhandler
>> OperationalError: (1071, 'Specified key was too long; max key length is
>> 767 bytes')
>>
>> Temporary fix was to change from True to False.
>>
>> class DatabaseStoredFile:
>>
>> web2py_filesystem = True
>>
>> (I did already have the web2py_filesystem table of course)
>>
>
--
