I looked back through my code and didn't find an instance where I had
custom links on a grid with a left join. And, I've been coding in web2py
since 2011.
-Jim
On Thursday, October 8, 2020 at 10:38:12 AM UTC-5, Vlad wrote:
>
> Jim,
>
> Thank you very much for your help,
>
> This is a perfect
Jim,
Thank you very much for your help,
This is a perfect solution for me. It just took me time to figure out what
was going on.
I don't think that this can be classified as a bug in web2py. It's just
very confusing for anybody who encounters this situation. However, if I am
the only one who
Vlad
The behavior is exactly as you said it is.
I don't know if I'd go as far as saying this is a problem with web2py. I
got around it by using this instead of the try/except in GetCartsGridLink
id = row.cart.id if 'cart' in row else row.id
I know it isn't ideal and isn't what you were
Just realized that there is another field, virtual one, referenced in the
code. In case the problem doesn't reproduce without it, here is the
definition (but I don't think that this would be necessary):
db.cart.count = Field.Virtual(lambda row:
Sure, the sample data attached (are these 2 tables enough?), and the models
are as follows:
db.define_table('cart',
Field('description','string',default='My Cart (%s)' %
str((datetime.now().strftime("%m/%d/%Y %I:%M%p",
auth.signature)
db.define_table('cart_ownership',
any chance you have a model and a small sample-set of data you could share
that cause the inconsistencies to be shown? Just 3 records or so in each
table that can show the inconsistency?
On Thursday, October 8, 2020 at 7:38:48 AM UTC-5, Vlad wrote:
>
> Yes, there is always a corresponding
Yes, there is always a corresponding record in the second table (doesn't
have to be, but I do clean up ownerless carts, so when I am testing things,
the corresponding record is always there).
Here is the complete creation of the grid (where GetCartsGridLink is the
function that now has try/except
I will take a look tomorrow to see if I can code something up to reproduce
the error.
Which tackle are you setting as the 'primary' table, by that I mean what
field are you specifying in the field_id parameter? And, is there ALWAYS a
matching record in the secondary table?
Oh, just thought of
Jom, you said " I'm having trouble understanding why you need the
try/except" - this is exactly the trouble I'm having too :)
I do use the left join. So I should simply specify the table name - correct?
Well, if I do - then the grid itself works fine, but once I click "view" or
"edit" - it
I'm having trouble understanding why you need the try/except. To me it
seems like "if you specify a left" -> you need to use the table name. "if
you don't specify a left" -> omit the table name
Do you have an occasion where sometimes different rows in the same grid
require you to specify the
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
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
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
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
14 matches
Mail list logo
