Forum OpenACS Development: Re: General Comment editing issue Solved, and the true source is in core.

3: Re: General Comment editing issue Solved, and the true source is in core. (response to 2)

Posted by Brian Fenton on 02/16/10 10:40 AM

Hi Jim

I agree that's probably not what you would intuitively expect with db_multirow, but that behaviour is documented - you can use the -unclobber parameter to not overwrite local variables.

https://openacs.org/api-doc/proc-view?proc=db_multirow&source_p=1&version_id=

cheers!
Brian

4: Re: General Comment editing issue Solved, and the true source is in core. (response to 3)

Posted by Jim Lynch on 02/16/10 11:16 AM

Heya Brian...

Thing is, it's inconsistant. If you don't supply a code block, it doesn't overwrite the vars. If you do supply the code block, the vars "should" (IMO) only be visible within it. I didn't know about the unclobber thing tho. Looking at db_foreach, there's no such issue, or at least no "-unclobber" option. For consistancy's sake, it should be the opposite: if, on the small chance, someone wants the vars visible beyond the block, there should be a -clobber option, and it should also be in loops like db_foreach.

If you like, you can apply the concept from "Apple User Interface Guidelines": don't make (the programmer) remember any more than he has to, certainly not: "so there's a foreach, a db_foreach, a db_multirow, and in only one of those, vars are clobbered outside a supplied block, and then only when it's supplied"... nightmarish... That's exactly the kind of thing that's going to chase devs away.

-Jim

7: Re: General Comment editing issue Solved, and the true source is in core. (response to 4)

Posted by Dave Bauer on 02/16/10 02:06 PM

Jim

This code block

foreach value [list a b c] {
#do something
}

the varaible "value" is still set after the foreach code block. db_foreach and db_multirow behave exactly the same way.

So for a Tcl programmer it is expected behavior. The only thing you need to remember is that the variables matching the columns in the query are created within the loop so they can overwrite variables in the caller since that is the level the code block runs at, and they exist in the caller's level after the code block completes.

5: Re: General Comment editing issue Solved, and the true source is in core. (response to 3)

Posted by Dave Bauer on 02/16/10 01:17 PM

Actually unclobber only works if the variable was previously set. If it was not set before the multirow it will not be cleaned up after the multirow so you end up with new variables.

This makes it tricky with using template::list since naturally you want the filter names to match the varaible the filter is filtering for, and if the filter is not set, it will be set at the end of the multirow causing the filter to be applied incorrectly.

6: Re: General Comment editing issue Solved, and the true source is in core. (response to 5)

Posted by Jim Lynch on 02/16/10 01:53 PM

Not sure, are you saying the behavior is inconsistant but this is needed because db_multirow is used with template::list?

-Jim