if you like , you can work onto DAL.py brad. new design of DAL.py is gonna be more powerful, and will be a lot more modular but it will take some chunk of time so we regard it as low priority.
On Wed, Nov 24, 2010 at 12:26 AM, brad <[email protected]> wrote: > My mistake, Massimo. Sorry. > > On Nov 22, 10:40 pm, mdipierro <[email protected]> wrote: > > Talking about sql.py or dal.py. dal.py is an experimental rewrite of > > sql.py. dal.py is not used in web2py. dal.py has not been updated in > > long time. > > > > Massimo > > > > On Nov 22, 8:48 pm, Mariano Reingart <[email protected]> wrote: > > > > > > > > > > > > > > > > > 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 Reingarthttp://www.sistemasagiles.com.arhttp:// > reingart.blogspot.com >
