On Mon, Nov 22, 2010 at 10:27 PM, brad <[email protected]> wrote: > I tested further and am not sure now about my proposed fix. > > In dal.py, there seem to be two approaches to user-defined primary > keys: > > One is to assume that only special tables have an > attribute ._primarykey, and run special case code if hasattr(self, > "_primarykey"), e.g.: > > if hasattr(self,'_primarykey'): > rtablename,rfieldname = ref.split('.') > rtable = self._db[rtablename] > rfield = rtable[rfieldname] > # must be PK reference or unique > if rfieldname in rtable._primarykey or > rfield.unique: > > > The other is to assume all tables have the ._primarykey attribute and > use it without testing for existence, e.g.: > > > if not orderby and tablenames: > sql_o += ' ORDER BY %s' % ', '.join(['%s.%s'%(t,x) for > t in tablenames for x in (self.db[t]._primarykey or ['id'])]) > > ...which simply won't run if t._primarykey doesn't exist. > > Possible fixes: > > 1. Use defaulted access: self.db[t].get("_primarykey") > > 2. Always set ._primarykey: > > elif primarykey: > self._primarykey = primarykey > new_fields = [] > else: > new_fields = [ Field('id', 'id') ] > + self._primarykey = ["id"] > > I haven't spent near enough time in the DAL to know which is best. > Thoughts?
I think current dal.py approach is wrong, having a distinction on normal vs keyed tables raises this types of issues, adds unnecessary complexity to the code and model design, etc. IIRC Massimo said that assuming autonumeric id as primary keys was a mistake taken from other frameworks, and it is preventing using NOSQL and full power of some relational databases. Also, it makes more difficult to do lazy table definitions, migrations and fixtures. There is a thread about this in web2py-developers, maybe you can look there for further information. Best regards, Mariano Reingart http://www.sistemasagiles.com.ar http://reingart.blogspot.com
