Forum OpenACS Q&A: Weird behavior of db api, doesn't work within ns_sockcallback

Collapse
1: Weird behavior of db api, doesn't work within ns_sockcallback
Posted by Matthew Soldo on 09/12/02 12:49 AM
I am executing the following code:
set sql "select foo, bar from foobars where bat='asdf' limit 1"

db_0or1row get_ns_sockets $sql

If I execute this in a plain tcl file under the www directory of the
openacs installation, it works just fine. However I have the code
executing within a tcl proc that gets called via the ns_sockcallback
function when a certain socket becomes readable. When the code gets
executed I get the error below. I'm guessing that calling the db api
from within a socket callback is screwing up its execution. Does
anybody have any experience with this? Know a work around?

[11/Sep/2002:16:07:59][28490.3076][-socks-] Error: can't
read "rest": no such variable

can't read "rest": no such variable while
executing "db_qd_make_absolute_path "${rest}.${proc_name}."
$local_name" (procedure "db_qd_get_fullname" line 151)

invoked from within "db_qd_get_fullname $statement_name"
(procedure "db_0or1row" line 5)

invoked from within "db_0or1row get_ns_sockets $sql"
(procedure "mas_callbackfromServer" line 15)

invoked from within "mas_callbackfromServer sock16 r"

Collapse
2: Response to Weird behavior of db api, doesn't work within ns_sockcallback (response to 1)
Posted by Don Baccus on 09/12/02 01:25 AM
The query dispatcher makes some assumptions about how procs using the db api are called, and you've apparently broken one of them.  This is a bit fragile, unfortunately.  You may need to do the same thing that www/index.tcl does: specify the fully qualified query name rather than the relative query name.
Collapse
3: Response to Weird behavior of db api, doesn't work within ns_sockcallback (response to 1)
Posted by Matthew Soldo on 09/12/02 02:45 AM
That seems's to have solved the problem, thanks very much.
Collapse
4: Re: Response to Weird behavior of db api, doesn't work within ns_sockcallback (response to 3)
Posted by Kevin Murphy on 12/02/02 06:45 PM
Could somebody elaborate on this for a newbie's sake?  What's an example of a fully qualified query name?  I just put a db_foreach in a tcl proc in a page, and the query is blowing up as described (can't read "rest": no such variable).

Mind if I report this as a bug, if it is not already?

BTW, I'm being bad and not using an xql file.

Thanks,
Kevin Murphy

P.S.  Yes, I am going to plough through the source.  I think the OpenACS motto should be "OACS: do you think you're tough enough?"  Maybe a new Alex could be created that is a bit more menacing .... 😉

Collapse
5: Re: Weird behavior of db api, doesn't work within ns_sockcallback (response to 1)
Posted by Simon at TCB on 12/04/02 12:50 PM
As I understand it in a tcl library (-proc) file, the fully qualified name will be procedure name followed by query name i.e.

name="myproc.run_this_sql"

Whereas in a tcl/adp pair page, only the query name is required

Of course as you'll notice this does lead to quite a lot of duplication of identical queries based on context.

As for your problem, it sounds like a variable you've used in a query hasn't been set prior to calling the query in the script.

Usually, if your problem is query naming you'll get a

Querying: ''

in the log file, i.e. the dispatcher doesn't see the query at all.

Collapse
6: Re: Weird behavior of db api, doesn't work within ns_sockcallback (response to 1)
Posted by Dan Wickstrom on 12/04/02 02:07 PM
The error is occuring because the query dispatcher expects the path to the tcl script is not under the 'packages' directory.  This same error will also occur, if you didn't declare your tcl proc using ad_proc.  How is your proc declared, and where is it located in the file-system relative to the openacs installation?
Collapse
7: Re: Weird behavior of db api, doesn't work within ns_sockcallback (response to 6)
Posted by Dan Wickstrom on 12/04/02 03:14 PM
Ugh, I should have proofread that last one.  I meant to say: "The error is occuring because the query dispatcher expects the path to the tcl script to be under the packages directory."