Christian-
Thanks for the reply, I am very sorry I could not respond sooner.
Providing a full example for web2py issue #150 is hard, as my code runs
against a MS SQL database (hence the "primarykey" kind of table definition
instead of one that uses the normal "id" field for the key).
Maybe if I point out the type mismatch in the web2py source code, it will be
clear.
In gluon\dal.py, in the definition of the class Table, there is a method
called "insert" that is called to insert a record into a table:
def insert(self, **fields):
return self._db._adapter.insert(self, self._listify(fields))
The parameter in red above, being passed to the adapter's "insert" method,
is a list created from the "fields" dictionary by the _listify() function.
The code being called (self._db._adapter.insert) is also in gluon\dal.py, in
the definition of the class BaseAdapter:
def insert(self,table,fields):
query = self._insert(table,fields)
try:
self.execute(query)
except Exception, e:
if isinstance(e,self.integrity_error_class()):
return None
raise e
if hasattr(table,'_primarykey'):
return dict( [ (k,fields[k]) for k in table._primarykey ])
id = self.lastrowid(table)
if not isinstance(id,int):
return id
rid = Reference(id)
(rid._table, rid._record) = (table, None)
return rid
The line of code that throws the exception is in blue. The reason this
exception is thrown is that the variable "fields" is a list, not a
dictionary, but the contents of table._primarykey are string field names,
not integers. When the list 'fields' is indexed with the field name string
values, the exception is thrown stating the list must be indexed by
integers.
This problem will only be seen if the table has a PrimaryKey, rather than
using a normal field named "id" as the key.
If this is still not helpful, let me know and I can try a different way to
describe the issue.
Thank you very much for your attention,
--Mike Peper
m...@peper.org
On Sun, Mar 27, 2011 at 3:27 PM, howesc wrote:
> Mike,
> asking is always a good thing. lots of stuff flys by and sometimes things
> fall through the cracks.
> i just looked at your bug report, and honestly am having trouble following
> it (which might be why it has not been addressed yet). can you post the
> table definition and a post that fails? A full example so we can
reproduce
> the problem will help get an answer faster.
> thanks,
> christian
