But shouldn't it be the same for the grid and for the record of the grid? The difference confuses me - having to specify the table should be consistent when I use the grid for all the transactions of the grid, including view/edit etc..
In other words, having to specify the table is perfectly fine - but it should be consistent and I should as well specify the table for the view/edit action of the grid record. Different structures for the gird and fo the record of the grid seems inconsistent to me.It took me time to figure this out - now that I know how this works, I simply have the try/except to solve it - this makes practical sense, as it solves the problem, but it makes no logical sense. Do you know what I mean? Anybody who encounters such a situation will presumably be messed up and have to spend time figuring out what's going on. On Wed, Oct 7, 2020 at 10:22 PM Jim Steil <ato.st...@gmail.com> wrote: > I think that is a result of having a left join specified. With the left > join you now have to specify which table the field is in as well. > > Or, am I missing something? > > -Jim > > On Wed, Oct 7, 2020 at 9:13 PM Eliezer (Vlad) Tseytkin < > westgate6...@gmail.com> wrote: > >> Jim, >> >> Thank you for the suggestions. >> >> I do specify field_id (it wasn't there in the simplified code, but the >> complete code does have it). >> >> When I use a function, instead of the lambda, I indeed can have a >> solution, but at the same time it emphasizes that something is wrong: >> >> The links are now presented as such: >> >> links = [dict(header='View', body=GetCartsGridLink)] >> >> >> And the GetCarrsGridLink function as follows: >> >> def GetCartsGridLink(row): >>> >>> id = None >>> >>> try: >>> id = row.cart.id # this works for the grid itself >>> except: >>> id = row.id # this works for the view/edit of a record of the grid >>> >>> result = A(id, >>> _href=URL('manage', 'view_cart', args=id, >>> user_signature=True), >>> _target='blank') >>> >>> return result >> >> >> It does solve the problem, because try/except takes care of it, setting >> up the id based on the context. >> >> I feel there is something wrong with the very necessity of having to use >> try/except here. Why would it use different structures in the grid itself >> vs. view/edit a row of the grid??? >> >> The problem has been solved, but the mystery remains. I am still missing >> something about it... >> >> On Wed, Oct 7, 2020 at 4:48 PM Jim S <ato.st...@gmail.com> wrote: >> >>> I have a couple of ideas, but none are tested >>> >>> First, can you try adding the field_id parameter to your SQLFORM.grid() >>> call? I believe that tells this grid which is your 'primary' table. >>> >>> Secondly (this is the way I typically handle it) - instead of coding >>> everything in a lambda, call a function to build your buttons and just pass >>> it the id of the row. Then, in your function you can retrieve the entire >>> row and get all the data you need even if it isn't included in the grid >>> fields. >>> >>> Not sure that completely addresses your concern, but if you run through >>> those ideas it might help you onto a solution. >>> >>> -Jim >>> >>> >>> On Wednesday, October 7, 2020 at 1:44:41 PM UTC-5, Vlad wrote: >>>> >>>> Seems to me this is an inconsistency in the way how grid operates >>>> (which breaks it, as I show below, but, of course, most probably I am just >>>> missing something.) >>>> >>>> The following code crashes: >>>> >>>> query = db.cart >>>> fields = [db.cart.id] >>>> links = [dict(header='View', body=lambda row: str(*row.cart.id >>>> <http://row.cart.id>*))] >>>> grid = SQLFORM.grid(query, editable=True, details=True, >>>> links=links, fields=fields) >>>> >>>> This is because row.cart is undefined in the links. Instead, the links >>>> should be made as such: >>>> >>>> links = [dict(header='View', body=lambda row: str(*row.id >>>> <http://row.id>*))] >>>> >>>> Now this works. >>>> >>>> However, when I add more fields in the code, like this: >>>> >>>> fields = [db.cart.id, db.cart.description, db.cart_ownership.boss, >>>> db.cart_ownership.status, db.cart.count] >>>> >>>> Now in the links I can't use "row.id". It must be "row.cart.id" >>>> >>>> This by itself would be fine, I could just use *row.id <http://row.id>* >>>> or *row.card.id <http://row.card.id>* accordingly, depending on the >>>> fields used (though I would like to control this structure), but I am >>>> having the following problem further on: >>>> >>>> The grid described by the code >>>> >>>> query = db.cart >>>> fields = [db.cart.id, db.cart.description, db.cart_ownership.boss, >>>> db.cart_ownership.status, db.cart.count] >>>> links = [dict(header='View', body=lambda row: str(row.cart.id))] >>>> grid = SQLFORM.grid(query, editable=True, details=True, >>>> links=links, fields=fields) >>>> >>>> crashes when I try to view or edit a row of the grid. This is because >>>> the links takes row.cart.id in the grid itself, but expects row.id in >>>> edit- or view- actions (i.e. when editing or viewing a row). When viewing >>>> or editing a row, row.cart is undefined in the links, so row.cart.id >>>> crashes it (when "view" or "edit" buttons are clicked), while in the grid >>>> itself row.cart.id works just fine (and row.id would not work). >>>> >>>> What am I missing here? How do I control how this field should be >>>> expected in the links in the grid vs. in the view/edit a row of the grid? >>>> >>>> Here is still simplified but more complete code, in case I missed >>>> something important in a "shortcut" code above: >>>> >>>> query = db.cart >>>> fields = [db.cart.id, db.cart.description, db.cart_ownership.boss, >>>> db.cart_ownership.status, db.cart.count] >>>> links = [dict(header='View', body=lambda row: str(row.cart.id))] >>>> grid = SQLFORM.grid(query, >>>> editable=True, >>>> details=True, >>>> links=links, >>>> fields=fields, >>>> left = [db.cart_ownership.on(db.cart.id >>>> ==db.cart_ownership.cart)], >>>> field_id=db.cart.id, >>>> ) >>>> >>>> -- >>> Resources: >>> - http://web2py.com >>> - http://web2py.com/book (Documentation) >>> - http://github.com/web2py/web2py (Source code) >>> - https://code.google.com/p/web2py/issues/list (Report Issues) >>> --- >>> You received this message because you are subscribed to a topic in the >>> Google Groups "web2py-users" group. >>> To unsubscribe from this topic, visit >>> https://groups.google.com/d/topic/web2py/UGhYBMwmXec/unsubscribe. >>> To unsubscribe from this group and all its topics, send an email to >>> web2py+unsubscr...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/web2py/257aa85d-41f2-4b2e-a59a-bd1980c83efco%40googlegroups.com >>> <https://groups.google.com/d/msgid/web2py/257aa85d-41f2-4b2e-a59a-bd1980c83efco%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- >> Resources: >> - http://web2py.com >> - http://web2py.com/book (Documentation) >> - http://github.com/web2py/web2py (Source code) >> - https://code.google.com/p/web2py/issues/list (Report Issues) >> --- >> You received this message because you are subscribed to a topic in the >> Google Groups "web2py-users" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/web2py/UGhYBMwmXec/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> web2py+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/web2py/CABZ%2BKCCVY37AMAFQ6FxgpJvX3X%3Dbr9gFBU68c74HpUJw3pEa%2BQ%40mail.gmail.com >> <https://groups.google.com/d/msgid/web2py/CABZ%2BKCCVY37AMAFQ6FxgpJvX3X%3Dbr9gFBU68c74HpUJw3pEa%2BQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- > Resources: > - http://web2py.com > - http://web2py.com/book (Documentation) > - http://github.com/web2py/web2py (Source code) > - https://code.google.com/p/web2py/issues/list (Report Issues) > --- > You received this message because you are subscribed to a topic in the > Google Groups "web2py-users" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/web2py/UGhYBMwmXec/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > web2py+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/web2py/CAERBpoBS7skdN8q%3DzYwfA01WK-TKEHXkvq0iX%3Df4ghMRVbPzyw%40mail.gmail.com > <https://groups.google.com/d/msgid/web2py/CAERBpoBS7skdN8q%3DzYwfA01WK-TKEHXkvq0iX%3Df4ghMRVbPzyw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/web2py/CABZ%2BKCDDLn4LQRq83HhU6tsd9myU%3Du2Ksaf1cLu1ujKAVyjGhw%40mail.gmail.com.