smartgrid with lazy_tables=True and postgresql fails to show references about web2py

[niphlod]

From [email protected] on October 15, 2012 05:44:43

Status: Accepted

[niphlod]

From [email protected] on October 15, 2012 06:37:48

Just confirming that the problem persists in 2.1.1 (as expected since it came out just a few minutes after this bug report).

Also I forgot to mention that the steps to reproduce build on the admin "new simple app" skeleton.

[niphlod]

From [email protected] on October 15, 2012 07:02:19

I acknowledge this happens but if the reference tables are lazy that means they are not defined unless explicitly called. There is no way for the grid to know about them. Try:

def index2():
db.y, db.z
return dict(grid=SQLFORM.smartgrid(db.x))

or

def index2():
return dict(grid=SQLFORM.smartgrid((db.x,db.y,db.z)))

[niphlod]

From [email protected] on October 15, 2012 07:34:00

The first method indeed works. However, in this example there are only 2 referencing tables, there are projects where there are quite a lot more and it's tiresome to have to refer to all of them before calling smartgrid, when the grid is supposed to be smart about this.

This also makes it impossible to use lazy_tables with functions that require introspection of the database schema. I don't have any great solutions apart from this kind of functions somehow (maybe raising an exception) forcing a rebuild of the request environment, with lazy_tables=False. Which hopefully shouldn't make them much slower since lazy is so much faster anyway.

Either way, thanks for the workaround.

[niphlod]

From [email protected] on October 16, 2012 08:41:10

Do you get a performance benefit from the lazy_tables?

[niphlod]

From [email protected] on October 16, 2012 08:55:37

I frankly haven't measured yet, I've only recently started using web2py, and the website I got this problem in (I used smartgrid quite a lot in the backend), isn't in the production phase yet. I'm guessing yes at this time because most frontend pages only use a small portion of the tables but it's really just a guess. At this time I'm still only testing it for bugs and not for performance yet.

I guess I could put the backend in a different app using the same database, that used lazy_tables=False in the model, that might be the best solution in this kind of scenario.

[niphlod]

not sure if this will ever be solvable. @leonelcamara : do you still feel the need for this "feature" ?

[niphlod]

going to close this unless @leonelcamara chimes in in the next week.
I stand by the "original chicken-egg issue" that if you want lazy_tables you can't expect smartgrid to roll-out every possible linked table without - for all intents and purposes - unlazying all tables.