hasttr/__getattr__ loop in schema.Column

[J Pellerin]

There appears to be a loop in {{{schema.Column.getattr}}}. When I run under pdb, it looks like an infinite loop: the column calls {{{hasattr(self, 'table')}}} in _set_parent, that results in {{{self.getattr('table')}}}; {{{getattr}}} then calls {{{hasattr(self,'_impl')}}}, which calls {{{self.getattr('_impl')}}}, which calls {{{hasattr(self, '_impl')}}} ... and so on. If you add a print in {{{getattr}}} you can see {{{getattr('_impl')}}} is called many, many, many more times than necessary (992 per column!).

I'm not sure why this works at all, but I think it might be working (outside of my test runner, where it locks) because it raises a recursion error inside of a hasattr() call, which traps and discards it.

I've attached an example that monkeypatches {{{Column.getattr}}} to trace the calls and print stats. Much easier than hitting 's' in pdb 992 times.

The implementation in {{{check_getattr()}}} in the attachment (minus the stat collection) is my proposed fix.

[J Pellerin]

Demonstrates hasattr/getattr loop

[Mike Bayer]

holy. crap.

ok, the fix is to just call the dict instead of using hasattr, changeset:1024

running alltests.py with sqlite now is 3-4 seconds faster.

going to release 0.1.2 right now, i cant have a bug like that out there....