you really should post what you're trying to do with the table.
lazy_tables=True "activates" the lazy definition of the table, meaning that
it gets really defined only if it's accessed as db.tablename, db[tablename]
or db.__getattr__(tablename).
The only thing you can't do "in the same way" with lazy_tables=True is
tablename = db.define_table('whatever', Field('whatever'))
With lazy_tables=False, tablename is a reference to db.whatever
(db['whatever'], db.__getattr__('whatever')).
with lazy_tables=True, the variable tablename is None, because define_table
with lazy_tables doesn't return anything (as it's supposed to).
On Tuesday, November 27, 2012 1:42:29 PM UTC+1, Joe Barnhart wrote:
>
> I'm running into a weird "lazy tables" bug. I have about 32 tables
> defined and I'm running into a error when I try to open a controller on a
> table that references another. The referenced table doesn't show up in the
> DAL and web2py throws an error.
>
> I can see the table during "define_table" and I see it added to the
> _LAZY_TABLES list. But later, when the table is referenced, it does NOT
> show up in the list when I am performing _getattr_ on the name of the table
> in the DAL instance. It's like it magically disappears between the
> "define_table" and the time the controller is executed.
>
> It seems like the problem is here, in the dal.py file:
>
>
> def define_table(
> self,
> tablename,
> *fields,
> **args
> ):
> if not isinstance(tablename,str):
> raise SyntaxError, "missing table name"
> elif hasattr(self,tablename) or tablename in self.tables:
> if not args.get('redefine',False):
> raise SyntaxError, 'table already defined: %s' % tablename
> ...etc
>
>
> The call to "hasattr" is processed as a call to the routine "__getattr__"
> shown below:
>
>
> def __getattr__(self, key):
> if ogetattr(self,'_lazy_tables') and \
> key in ogetattr(self,'_LAZY_TABLES'):
> tablename, fields, args = self._LAZY_TABLES.pop(key)
> return self.lazy_define_table(tablename,*fields,**args)
> return ogetattr(self, key)
>
>
> But __getattr__ throws an exception if the key is not present, yet the
> define_table code which calls it does not look for or process the
> exception. Something is amiss in this code but I'm not in tune enough to
> figure out the original intent of "hasattr" in this context.
>
> Am I missing something? (probably)
>
> -- Joe B.
>
>
>
--