again, it seems to work but I didn't check the code to see if it is supported.
when you pass a table to the grid constructor, search, orderby etc are done against the "real" data of the table. So, if you're going to display, e.g., a table with a user_id fields referenced to the auth_user table, you get a "user_id" column with the "first_name - last_name - id" value. But if you search "tom" you get nothing, the search is done on the actual table, not in the referenced one. This is "smart" because you'd need to fetch all the relations every time and search/orderby through those. In addition, computed refs like yours are really heavy to search through..... it's a single count() for every row out there. In a word, if you pass the table, the search is done on the db engine, not in the complex logic that lambdas do. Anyway, it seems that for simple joins, if you have something like myq = db.auth_event.user_id == db.auth_user.id grid = SQLFORM.grid(myq) works fine for ordering/searching. On Monday, August 6, 2012 11:23:50 PM UTC+2, weheh wrote: > > Thanks for the responses. @Niphlod: I'm not sure what you mean by a full > queryset. Can you elaborate, please? On Monday, August 6, 2012 11:23:50 PM UTC+2, weheh wrote: > > Thanks for the responses. @Niphlod: I'm not sure what you mean by a full > queryset. Can you elaborate, please? --