OK, so I guess the answer is to ditch the virtual field and go with a regular field, then compute the field before putting up the grid. Lambda is nice in my failed implementation because it iterates automatically. I wonder if I can do the assignment without having to loop while updating? In other words can I avoid: for host in db(db.host).select(): # create count # update host table Anybody know how to do this in 1 line?
On Tuesday, August 7, 2012 5:45:17 AM UTC+8, Niphlod wrote: > > 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? > > --
