Will do. On 19 Jan 2010, at 22:16, mdipierro <[email protected]> wrote:
> I guess it is not upgrading the file. Let us know when you find out > the solution to the problem. > > On Jan 19, 12:55 pm, Carl <[email protected]> wrote: >> Looks like a GAE quirk! >> I have 1.74.6 and it has the line 425. But GAE isn't playing ball. >> >> I guess you can leave this one with me! >> >> thanks for all your help and sorry it turned out to be GAE (as we >> suspected!)! >> >> 2010/1/19 mdipierro <[email protected]> >> >>> if isinstance(fieldtype, SQLCustomType): >> >>> should be >> >>> if isinstance(fieldtype, gluon.sql.SQLCustomType): >> >>> But that bug is not in 1.74.6. I do not have line 418, have line >>> 425: >> >>> if isinstance(fieldtype, gluon.sql.SQLCustomType): >> >>> I remember fixing that some time ago. >> >>> Massimo >> >>> On Jan 19, 12:39 pm, Carl <[email protected]> wrote: >>>> From v1.74.6 running upon GAE: >> >>>> File >>> "/base/data/home/apps/testenvoy/basicss.339281047942238178/gluon/ >>> main.py", >>>> line 469, in wsgibase >>>> session._try_store_in_db(request, response) >>>> File >>> "/base/data/home/apps/testenvoy/basicss.339281047942238178/gluon/ >>> globals.py", >>>> line 346, in _try_store_in_db >>>> table._db(table.id == record_id).update(**dd) >>>> File >>> "/base/data/home/apps/testenvoy/basicss.339281047942238178/gluon/ >>> contrib/gql.py", >>>> line 716, in update >>>> table[field].type, db) >>>> File >>> "/base/data/home/apps/testenvoy/basicss.339281047942238178/gluon/ >>> contrib/gql.py", >>>> line 418, in obj_represent >>>> if isinstance(fieldtype, SQLCustomType): >>>> NameError: global name 'SQLCustomType' is not defined >> >>>> 2010/1/19 mdipierro <[email protected]> >> >>>>> 1.74.6 please >> >>>>> On Jan 19, 11:02 am, Carl <[email protected]> wrote: >>>>>> thanks for the URL. >>>>>> I've been doing a "binary search" with versions but I've not >>>>>> checked >>>>> every >>>>>> version. here's what I've found so far: >> >>>>>> v1.67.2 . works locally & GAE >>>>>> v1.68.2 . works locally & GAE >>>>>> v1.69.1 . works locally & GAE >>>>>> v1.70.1 . works locally & GAE >>>>>> v1.71.1 . works locally. GAE reports 'Internal error' on start- >>>>>> up. >>>>>> v1.71.2 . works locally. GAE reports 'Internal error' on >>>>>> submitting >>>>>> registration form >>>>>> v1.72.3 . works locally but fails on GAE at 'gluon/main.py", line >>> 469, >>>>>> session._try_store_in_db' >>>>>> v1.73.1 . fails locally at 'gluon\globals.py", line 385, in >>>>>> _try_store_on_disk' >>>>>> v1.74.1 . fails locally at 'gluon\globals.py", line 375, in >>>>>> _try_store_on_disk' >> >>>>>> Log output for v1.71.1 GAE >> >>>>>> NameError: global name 'SQLCustomType' is not defined >> >>>>>> That logout doesn't look very helpful. >> >>>>>> Let me know what version you'd like to see a trace from the log >>>>>> for. >> >>>>>> 2010/1/19 mdipierro <[email protected]> >> >>>>>>> http://web2py.com/examples/static/xxxx/web2py_src.zip >> >>>>>>> where xxxx is a version. Only some versions are stored. >> >>>>>>> I will look at your code asap. >> >>>>>>> On Jan 19, 5:58 am, Carl <[email protected]> wrote: >>>>>>>> Massimo, I've sent you a stand-alone example that is as small >>>>>>>> as >>>>>>>> possible. I don't have upload access to Files in this group, >>> hence >>>>> the >>>>>>>> direct email. >> >>>>>>>> I was using Web2py v1.67.2 and it was only an upgrade to >>>>>>>> v1.74.5 >>> that >>>>>>>> produced this error. >> >>>>>>>> I am willing to test the code with each version of Web2py since >>>>>>>> v1.67.2 to narrow down the change (if you think that would help >>> you >>>>>>>> debug). >> >>>>>>>> Where can I get these versions of web2py? >> >>>>>>>> On Jan 18, 2:14 pm, Carl <[email protected]> wrote: >> >>>>>>>>> hi, >> >>>>>>>>> I made some progress. The problem looks to be in the area of >>>>> writing >>>>>>>>> data to GAE. Until I do this I can register and login >>> successful >>>>>>>>> (provided I tweak the code not to care about this populated >>> data). >> >>>>>>>>> Once I call the populate() function below I can no longer >>> register/ >>>>>>>>> login. >> >>>>>>>>> class Salutations(): >>>>>>>>> def __init__(self, db, T): >>>>>>>>> (self.db, self.T) = (db, T) >> >>>>>>>>> def populate( self): >>>>>>>>> ''' >>>>>>>>> Envoy defines a short list of salutations >>>>>>>>> Salutations help build a relationship with a >>>>>>>>> client >>>>>>>>> ''' >> >>>>>>>>> T = self.T >>>>>>>>> salutations= ( >>>>>>>>> (10, T('Mr')), >>>>>>>>> (20, T('Ms')), >>>>>>>>> (30, T('Mrs')), >>>>>>>>> (40, T('Miss')), >>>>>>>>> (50, T('Dr')), >>>>>>>>> (60, T('Prof.')) ) >> >>>>>>>>> for salu in salutations: >>>>>>>>> dbsals = self.db >>>>>>>>> (self.db.salutations.salutation_order==salu[0]).select() >>>>>>>>> if not dbsals: >> >>>>> self.db.salutations.insert(salutation_order=salu[0], >>>>>>>>> salutation=unicode(salu[1])) >>>>>>>>> else: >>>>>>>>> dbsals[0].update_record( >>> salutation_order=salu[0], >>>>>>>>> salutation=unicode(salu[1])) >> >>>>>>>>> return( len(salutations)) >> >>>>>>>>> I tried changing the unicode() calls to str() but it made no >>>>> material >>>>>>>>> difference. >> >>>>>>>>> Am I making a basic error in populate() ? >> >>>>>>>>> On Jan 16, 12:29 pm, Carl <[email protected]> wrote: >> >>>>>>>>>> Additional information... >> >>>>>>>>>> In thinking that perhaps GAE hadn't delete *all* my data and >>>>> hence >>>>>>> had >>>>>>>>>> hidden corruption I looked at an earlier version of my app. >> >>>>>>>>>> GAE allows me to run different versions of an app against the >>>>> same >>>>>>>>>> database (big table data). >> >>>>>>>>>> I ran my previous version that is built on Web2py 1.67.2 and >>> it >>>>>>>>>> registers/logins successfully. >>>>>>>>>> So although our issue is subtle at least it's on our side and >>> I >>>>> don't >>>>>>>>>> need to try talking to google staff :) >> >>>>>>>>>> On Jan 15, 9:20 pm, Carl <[email protected]> wrote: >> >>>>>>>>>>> I had deleted GAE's tables before contacting you; I've just >>>>> deleted >>>>>>> them >>>>>>>>>>> again but I get the same behaviour. There is perhaps a >>> subtle >>>>>>> difference >>>>>>>>>>> between dev_appserver and the real-deal GAE. >> >>>>>>>>>>> I'll put together a stand-alone app tomorrow. >> >>>>>>>>>>> 2010/1/15 mdipierro <[email protected]> >> >>>>>>>>>>>> One more test. What bothers me is that is works on >>>>> dev_appserver >>>>>>> but >>>>>>>>>>>> not when deployed. There must be some corrupted data in >>> the >>>>>>> database. >>>>>>>>>>>> Is it an option for you to delete all data on GAE? >> >>>>>>>>>>>> On Jan 15, 12:22 pm, Carl <[email protected]> wrote: >>>>>>>>>>>>> I've taken out the orderby clauses but the login >>> failure >>>>> still >>>>>>> happens >>>>>>>>>>>> (I've >>>>>>>>>>>>> had those clauses in for earlier versions of web2py but >>> it >>>>> was >>>>>>> worth >>>>>>>>>>>>> looking). >> >>>>>>>>>>>>> Perhaps these two statements (default.py in user() ) >>> are >>>>> the >>>>>>> issue on >>>>>>>>>>>> GAE? >>>>>>>>>>>>> db.auth_user.billing_country.requires = >>>>>>> IS_NULL_OR(IS_NOT_EMPTY()) >>>>>>>>>>>>> db.auth_user.country.requires = >>> IS_NULL_OR(IS_NOT_EMPTY()) >> >>>>>>>>>>>>> I am using a custom form which doesn't not display >>> these >>>>> two >>>>>>> fields so >>>>>>>>>>>> I've >>>>>>>>>>>>> added these two statements to keep the registration >>> process >>>>>>> happy which >>>>>>>>>>>>> would otherwise want values from the user for them. >> >>>>>>>>>>>>> in db.py both fields have the clause: >>>>>>>>>>>>> requires=IS_NULL_OR(IS_IN_DB(db,db.iso3166.id >>>>> ,'%(country)s'))) >> >>>>>>>>>>>>> Does that aim/explanation make sense to you? The code >>> is >>>>> quite >>>>>>> old but >>>>>>>>>>>>> perhaps Web2py is translating to GAE in a subtley >>> different >>>>>>> way? If I >>>>>>>>>>>> remove >>>>>>>>>>>>> both statements then registration fails so I can't >>> simply >>>>>>> remove them to >>>>>>>>>>>>> test if the app works on GAE. >> >>>>>>>>>>>>> Is there an alternative approach I could take? At least >>> to >>>>> test >>>>>>> further? >> >>>>>>>>>>>>> 2010/1/15 mdipierro <[email protected]> >> >>>>>>>>>>>>>> I see a lot of orderby in those validators that >>> create >>>>>>> problems. >> >>>>>>>>>>>>>> I think the problem is there. >> >>>>>>>>>>>>>> Try remove the orderby and see if the error goes >>> away. >> >>>>>>>>>>>>>> If it does there are two options: >>>>>>>>>>>>>> 1) you need an index >>>>>>>>>>>>>> 2) the query is somehow invalid on GAE >> >>>>>>>>>>>>>> Massimo >> >>>>>>>>>>>>>> On Jan 15, 11:17 am, Carl <[email protected]> >>> wrote: >>>>>>>>>>>>>>> I made the changes you listed but the failed login >>>>> still >>>>>>> persists >>>>>>>>>>>> (you >>>>>>>>>>>>>>> probably expected it to but I was forever hopeful! >>> :) >> >>>>>>>>>>>>>>> I'll see if I can create a small app that >>> replicates >>>>> the >>>>>>> issue and >>>>>>>>>>>> send >>>>>>>>>>>>>> it >>>>>>>>>>>>>>> to you. >>>>>>>>>>>>>>> thanks for your time. >> >>>>>>>>>>>>>>> 2010/1/15 mdipierro <[email protected]> >> >>>>>>>>>>>>>>>> I do not know why you experience the behavior >>> that >>>>> you do >>>>>>> but there >>>>>>>>>>>>>>>> are some errors in those commented lines: >> >>>>>>>>>>>>>>>> 1) >> >>>>>>>>>>>>>>>> #cdrdb.Field('country', db.iso3166, >> >> ... >> >> read more ยป > -- > You received this message because you are subscribed to the Google > Groups "web2py-users" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected] > . > For more options, visit this group at > http://groups.google.com/group/web2py?hl=en > . > >
-- You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
