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 >> >
