Home
The Toolkit for Online Communities
17240 Community Members, 1 member online, 1875 visitors today
Log In Register
OpenACS Home : Forums : OpenACS Q&A : Where is the table user_arguments?

Forum OpenACS Q&A: Where is the table user_arguments?

Icon of envelope Request notifications

Collapse
Posted by Steve Manning on
I'm going slightly crazy trying to work out how this works. The acs_subsite package has a proc called package_plsql_args in package-procs.tcl which very conveniently returns the arguments of a plsql/plpgsql function.

The proc has the following sql select:

    return [db_list select_object_type_param_list {
    select args.argument_name
                    from user_arguments args
                    where args.position > 0
                  and args.object_name = upper(:function_name)
                  and args.package_name = upper(:package_name)
    }]

I can't find the table 'user_arguments' to which this refers yet it works! Its used by e.g bt_bug in the bug tracker and that is working - I know cos I broke it and thats what lead me here.

Could someone please put me out of my misery and point out my stupid mistake :)

Ta
    Steve

Collapse
Posted by russell muetzelfeldt on
check package-procs-(postgresql|oracle).xql to see how that is actually being handled now... the former contents of user_arguments now seem to live in acs_function_args...
Collapse
Posted by Steve Manning on
Thanks.

Your quite right there is a query in package-procs-postgresql.xql which selects from acs_function_args. I didn't look in the xql because the db_list provided its own select statement. So I have learnt 2 things:

1. You can have a query in the xql and in the proc and the one in the xql overides the one in the proc (I would have expected this to be the other way around so that the query name can be overloaded easily in the proc).

2. The select statement in the proc is superfluous and could be removed. In fact if it points to a no existant table it perhaps should be removed to avoid confusion.

Does this sound right?

    Steve

Collapse
Posted by Jarkko Laine on
Steve,

1. The "overloading" has to be this way. It wouldn't work the other way round. An example: you use a SQL/92 outer join in a general query. This happens not work in oracle so you have to write the query using oracle's own syntax in -oracle.xql. Now if the query in curly braces (or general xql file) would override the one in oracle file, this query would never work with oracle. I.e. the query in curlies is a default query, used if nothing with that query name can be found from xql files.

So the order is: 1. rdbms specific xql, 2. generic xql, 3. curlies. Of course the normal practice nowadays is not to put anything inside the curlies, so yes, you should remove the query from the tcl file.

The example I gave is actually a bad one, since you should only use such queries in general places that really work with all (both) rdbms's. But I think it should explain the reason for the parse order.

Collapse
Posted by Steve Manning on
Indeed that makes perfect sense. Thank you.

    Steve
Collapse
Posted by Malte Sussdorff on
Can we make it a rule, that no new code makes it into the CVS as long as it has SQL queries in the curlies? This is definitly confusing for newcomers. Though I have to agree that developing code is considerably easier with the queries in the TCL file, but hey, we got query-extractor :).
Collapse
Posted by Jeff Davis on
I think we should make it a rule that we make no new rules until we adhere to the rules we already made.
Collapse
7: Rule Book (response to 6)
Posted by Malte Sussdorff on
Can we post a rule book somewhere? Or, if it exists, make it more prominent at e.g. the doc section?

Just a n-pager stating: If you want to develop for the OpenACS core, these are the rules and good principles you should be following. Obviously, the rule about taking out SQL queries from tcl files should be high on that list :-).

Collapse
Posted by Mark Aufflick on
Malte - it's great to have boundaries on things, but I think you are being a bit restrictive limiting us to *just* n pages ;)
Collapse
Posted by russell muetzelfeldt on
c'mon mark... so you want (n' = n + 1) pages, and soon enough the documentation is infinitely long and then *noone* will read it...
Collapse
Posted by Jade Rubick on
I think this is a really good idea. If I'm given admin access on an ETP instance, I'll even volunteer to maintain this page. (I could do it on rubick.com, but openacs.org makes more sense).

A good start would be Jun's list of best practices:

http://www.infiniteinfo.com/openacs/things2remember.html

I'd probably start with that.

Collapse
Posted by Jade Rubick on
One rule for documentation I'd propose is that we don't require anybody to do anything that we don't have documentation for. :-)

For example, if we're going to require namespaces in packages, then we better damn well link to a place that explains how to do it. Why would be nice as well. (I have started documentation on this particular item)

Collapse
Posted by Jun Yamog on
Hi Jade,

I have given the doc to Joel.  And hopefully it can be maintained in a central place.  I am not sure if it did make into the docs though.

I am happy to put in your additions.  Maybe we can just put it into file storage.