Still can't solve this problem. here is the new code, which I *think* matches your recommendation:
row = jodb(jodb.joke.id==jokenum).select().first() jodb.pending.insert(**row.as_dict()) And I still get the seq error for the table: <class 'psycopg2.OperationalError'> currval of sequence "pending_id_seq" is not yet defined in this session So, having spent over 5 hours on this, I'm stuck. These truly are rare problems but really counter-productive when something just seems broken somewhere in the stack. No forward progress; no apparent solutions. On Monday, April 16, 2012 7:21:49 PM UTC-7, Lewis wrote: > > I have restarted postgresql. I have deleted the table and the migration. > I have tried to do a "fake migration" within web2py. Now, this table > seems to be corrupted somehow because the currval for the id_seq of the > table won't update. Wow. What a big mess. > > Any clues on how to recover from this? > > On Monday, April 16, 2012 5:58:00 PM UTC-7, Lewis wrote: >> >> Thanks. Certainly the documentation. I'll give some thought to whether >> there is some other behavior. >> >> Now I have a deeper problem: >> >> <class 'psycopg2.OperationalError'> currval of sequence "pending_id_seq" >> is not yet defined in this session >> >> This refers to the id field. I'll change the model and go out to >> pgadmin and manually delete the table. Then, I'll put the defintion back in >> the model so that DAL can create a clean table. >> >> On Monday, April 16, 2012 5:42:53 PM UTC-7, Anthony wrote: >>> >>> I think I am trying to do something very simple, but I don't understand >>>> row objects (why can't they be a normal Python type instead of a web2py >>>> class?). >>> >>> >>> It acts like a dictionary, but you can do row.field instead of having >>> to do row['field']. It also has a way of storing and returning the >>> value of expressions requested in the query, and it includes special lambda >>> functions to update and delete the record. You can't do any of that with a >>> normal Python type. If you want a plain dict, just do row.as_dict(). >>> >>> Regarding your code, the problem is that you are working with a Rows >>> object, not a Row object. The select() method returns a Rows object, which >>> acts like a list of Row objects (even if it only returns one row). From the >>> book (with regard to the select method): >>> >>> It returns an iterable object of class gluon.sql.Rows whose elements >>>> are Row objects. gluon.sql.Row objects act like dictionaries, but >>>> their elements can also be accessed as attributes, like >>>> gluon.storage.Storage. The former differ from the latter because its >>>> values are readonly. >>> >>> >>> If you want to extract the first row from a Rows object, do: >>> >>> row = db(query).select().first() >>> >>> To insert into another table: >>> >>> db.other_table.insert(**row.as_dict()) >>> >>> >>>> The row object and its strangeness is not described very well in the >>>> DAL section of the book. It's too magical. It's need to be more >>>> transparent. >>>> >>> >>> Are you saying we need better documentation (agreed), or that the >>> behavior or Rows and Row objects should change? If the latter, what would >>> you suggest? >>> >>> Anthony >>> >>
