Yes; here it is: 1. 2. 3. 4. 5. 6. 7. 8. 9.
Traceback (most recent call last): File "gluon/restricted.py", line 205, in restricted File "C:/Program Files (x86)/web2py/applications/NCAA_schedule/models/db.py" <http://127.0.0.1:8000/admin/default/edit/NCAA_schedule/models/db.py>, line 165, in <module> File "gluon/dal.py", line 6320, in define_table File "gluon/dal.py", line 742, in create_table File "gluon/dal.py", line 797, in migrate_table File "gluon/dal.py", line 6714, in __getitem__ KeyError: 'length_is_yards' The table definition follows: db.define_table('Pool', Field('Pool_name', 'string', required=True, unique=True), Field('Address1', 'string', length=60), Field('Address2', 'string', length=60), Field('City', 'string', length=60), Field('State', 'string', length=2), Field('Zip', 'string', length=15), Field('Nr_lanes', 'integer', required=True), Field('Length', 'integer', required=True), Field('Length_is_yards', 'boolean', required=True,default=True), Field('Has_moveable_bulkhead', 'boolean', required=True, default=False), format='%(Pool_name)s %(Nr_lanes)s') Line 165 is the last line of the statement (format=...). On Monday, September 17, 2012 3:15:08 PM UTC-6, Massimo Di Pierro wrote: > > Do you have a traceback with more information? > > On Monday, 17 September 2012 14:23:56 UTC-5, MichaelF wrote: >> >> Thanks. However, I refer to that field with upper case in all places. Can >> you tell me where the lower case 'pending' comes from? The field name has >> always been defined as upper case, and the app has been working up until I >> made that latest change. So I went into the db and changed the field name >> to start with lower case, then changed the model file to make it lower-case >> 'pending'. That worked, but now the next boolean field in the db.py file >> has an upper-case/lower-case problem. The field is "Length_is_yards" in >> both the db.py file and the db, and has been that way for weeks, and we've >> been through several db migrations for the past several weeks (not sure >> about on those particular tables, though). Now I get the KeyError as shown >> above, but this time it's for field 'length_is_yards'. It looks to me that >> web2py is assuming it's lower case. >> >> One of my migrations last week was the "fake_migrate_all=True" type; >> don't know if that's relevant. >> >> Also, in the .database file the field name is Length_is_yards (leading >> "L" is capital), as is the field name in the MySQL db. >> >> I'm confused. >> >> Michael >> >> On Monday, September 17, 2012 12:51:34 PM UTC-6, Massimo Di Pierro wrote: >>> >>> Field('Pending' <<< upper case >>> ... >>> <type 'exceptions.KeyError'> 'pending' <<< lower case >>> >>> >>> >>> On Monday, 17 September 2012 11:37:13 UTC-5, MichaelF wrote: >>>> >>>> I did a simple import of 'copy' and that got me by that first problem. >>>> But now I have the following problem: >>>> >>>> db.define_table('Person_certification', >>>> Field('Person', db.Person), >>>> ... >>>> Field('Pending', 'boolean', default = False), >>>> ... >>>> >>>> I get the following error on the line that defines field 'Pending' (and >>>> this is the first 'boolean' type in the file): >>>> <type 'exceptions.KeyError'> 'pending'I have not changed the >>>> underlying MySQL db yet; all the booleans are still char(1). Do I need to >>>> change them first to Tinyint(1)? I tried that; same error. >>>> >>>> Thanks. >>>> >>>> On Monday, September 17, 2012 9:21:37 AM UTC-6, MichaelF wrote: >>>>> >>>>> 1. What will I need to import to get it to recognize 'copy'? I run the >>>>> suggested code and get told that 'copy' does not exist. (I'm running 2.5; >>>>> what do I conditionally import?) >>>>> >>>>> 2. Are we doing a copy because all the adapters share the same 'types' >>>>> object? >>>>> >>>>> On Tuesday, August 7, 2012 3:48:35 PM UTC-6, Massimo Di Pierro wrote: >>>>>> >>>>>> On can always do: >>>>>> >>>>>> db=DAL('mssql://...') >>>>>> db._adapter.types = copy.copy(db._adapter.types) >>>>>> db._adapter.types['boolean']='TINYINT(1)' >>>>>> >>>>>> It should work. Can you please check it? >>>>>> >>>>>> On Tuesday, 7 August 2012 11:56:59 UTC-5, Osman Masood wrote: >>>>>>> >>>>>>> However, web2py maintains the promise of backwards compatibility. >>>>>>> One way is to have a 'tinyint_boolean' datatype for those who want to >>>>>>> use >>>>>>> tinyints as booleans. But that looks kind of messy and inelegant. >>>>>>> >>>>>>> An alternative is this: We could add a migration script to /scripts >>>>>>> to convert all boolean data types from CHAR(1) to TINYINT(1), and from >>>>>>> 'T' >>>>>>> to 1 and 'F' to 0. Also, when a table model is called in >>>>>>> define_table(), it >>>>>>> would check whether its boolean data types are CHAR or INT, and save >>>>>>> the >>>>>>> result somewhere (so it wouldn't have to keep checking.) If the server >>>>>>> is >>>>>>> restarted, it would once again perform this check. So, a user would run >>>>>>> the >>>>>>> migration script and simply restart the server. >>>>>>> >>>>>>> On Thursday, July 12, 2012 9:18:33 PM UTC+8, simon wrote: >>>>>>>> >>>>>>>> I have just come across this exact same issue. >>>>>>>> >>>>>>>> The web2py adapter converts boolean to char(1) but in MySQL the >>>>>>>> specification is that boolean is stored as tinyint with 0 and 1. So >>>>>>>> web2py >>>>>>>> adapter is incorrect. Not changing it perpetuates the mistake. >>>>>>>> >>>>>>>> >>>>>>>> On Sunday, 6 March 2011 05:14:49 UTC, Kevin Ivarsen wrote: >>>>>>>>> >>>>>>>>> I'm connecting to a legacy MySQL database (migrate=False) with a >>>>>>>>> lot >>>>>>>>> of fields declared BOOLEAN, and noticed that attempts to modify >>>>>>>>> these >>>>>>>>> fields with the DAL failed. The DAL issues a query like this: >>>>>>>>> >>>>>>>>> UPDATE sometable SET someflag='T' WHERE ... >>>>>>>>> >>>>>>>>> but this gets rejected by MySQL. >>>>>>>>> >>>>>>>>> Reading through dal.py, I see that the "boolean" type maps to >>>>>>>>> CHAR(1) >>>>>>>>> in MySQLAdapter, and represent() converts to "T" and "F" values. >>>>>>>>> However, the BOOLEAN type is a synonym for TINYINT(1) in MySQL, >>>>>>>>> with >>>>>>>>> values 0 or 1, according to: >>>>>>>>> >>>>>>>>> http://dev.mysql.com/doc/refman/5.0/en/numeric-type-overview.html >>>>>>>>> >>>>>>>>> I can trivially change this behavior in dal.py for my purposes, >>>>>>>>> but it >>>>>>>>> would be interested to try to incorporate this into the main >>>>>>>>> web2py >>>>>>>>> distribution. Unfortunately, the trivial change will break >>>>>>>>> backwards >>>>>>>>> compatibility for people who are already depending on the current >>>>>>>>> behavior. Any thoughts on how this could be done in a backwards- >>>>>>>>> compatible way, or is it too much of an edge case to worry about? >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Kevin >>>>>>>> >>>>>>>> --
