Forum OpenACS Q&A: Error send by Opeacs.

Collapse
Posted by H. shefaat on
Hi, I get this error message form the server and I dont know what cause this error!

can someone help? Thanks in advance

02/Oct/2002:09:18:56
    Error: Database operation "0or1row" failed (exception 
NSINT, "Query returned more than one row.")
Database operation "0or1row" failed (exception NSINT, "Query returned 
more than one row.")
    while executing
"ns_pg_bind 0or1row nsdb0 {
	select package_id from apm_packages where package_key 
= :package_key
    }"
    ("uplevel" body line 1)
    invoked from within
"uplevel $ulevel [list ns_pg_bind $type $db $sql"
    invoked from within
"db_exec 0or1row $db $full_name $sql"
    invoked from within
"set selection [db_exec 0or1row $db $full_name $sql]"
    ("uplevel" body line 2)
    invoked from within
"uplevel 1 $code_block "
    invoked from within
"db_with_handle db {
	set selection [db_exec 0or1row $db $full_name $sql]
    }"
    (procedure "db_string" line 7)
    invoked from within
"db_string apm_package_id_from_key {
	select package_id from apm_packages where package_key 
= :package_key
    } -default 0"
    (procedure "apm_package_id_from_key_mem" line 2)
    invoked from within
"apm_package_id_from_key_mem search"
    ("eval" body line 1)
    invoked from within
"eval $script"
    invoked from within
"ns_cache eval util_memoize $script {
	    list $current_time [eval $script]
	}"
    (procedure "util_memoize" line 20)
    invoked from within
"util_memoize "apm_package_id_from_key_mem $package_key""
    (procedure "apm_package_id_from_key" line 2)
    invoked from within
"apm_package_id_from_key search"
    (procedure "search_indexer" line 3)
    invoked from within
"search_indexer"
    ("eval" body line 1)
    invoked from within
"eval [concat [list $proc] $args]"
    (procedure "ad_run_scheduled_proc" line 43)
    invoked from within
"ad_run_scheduled_proc {f f 30 search_indexer {} 1033473296 0 t}"
Notice: Running scheduled proc 
notification::reply::sweep::scan_all_replies...
Notice: NOTIF- scan_all_replies starting
Debug: db_qd_get_fullname: following query in file: 
packages.notifications.tcl.reply-sweep-procs proc: 
notification::reply::sweep::scan_all_replies
Collapse
Posted by Jeff Davis on
Isn't this basically the same error you posted before...

https://openacs.org/bboard/q-and-a-fetch-msg.tcl?msg_id=0006Q4&topic_id=OpenACS&topic=11

In this case, "search" is mounted more than once and so the apm_package_id_from_key fails.

Collapse
Posted by Jeff Davis on
Also, I checked and there are calls to apm_package_id_from_key for the following modules even though they are not set as singleton-p:
 package_key  | singleton_p 
--------------+-------------
 clickthrough | f
 search       | f
 glossary     | f
 payflowpro   | f
Someone should either fix the apm_package_id_from_key or make the packages singleton-p t. I have not looked at the code really to figure out which is the right answer for each package.

Thanks for pointing this out, H. The system just should not ever let this happen and steps will be taken to prevent such errors in the future.

Collapse
Posted by H. shefaat on
Thanks Jeff, I remvoed the secound search but I get still the error (sorry for posting whole message!):
  Error: Database operation "0or1row" failed (exception NSINT, "Query returned more than one row.")
Database operation "0or1row" failed (exception NSINT, "Query returned more than one row.")
    while executing
"ns_pg_bind 0or1row nsdb0 {
	select package_id from apm_packages where package_key = :package_key
    }"
    ("uplevel" body line 1)
    invoked from within
"uplevel $ulevel [list ns_pg_bind $type $db $sql"
    invoked from within
"db_exec 0or1row $db $full_name $sql"
    invoked from within
"set selection [db_exec 0or1row $db $full_name $sql]"
    ("uplevel" body line 2)
    invoked from within
"uplevel 1 $code_block "
    invoked from within
"db_with_handle db {
	set selection [db_exec 0or1row $db $full_name $sql]
    }"
    (procedure "db_string" line 7)
    invoked from within
"db_string apm_package_id_from_key {
	select package_id from apm_packages where package_key = :package_key
    } -default 0"
    (procedure "apm_package_id_from_key_mem" line 2)
    invoked from within
"apm_package_id_from_key_mem search"
    ("eval" body line 1)
    invoked from within
"eval $script"
    invoked from within
"ns_cache eval util_memoize $script {
	    list $current_time [eval $script]
	}"
    (procedure "util_memoize" line 20)
    invoked from within
"util_memoize "apm_package_id_from_key_mem $package_key""
    (procedure "apm_package_id_from_key" line 2)
    invoked from within
"apm_package_id_from_key search"
    (procedure "search_indexer" line 3)
    invoked from within
"search_indexer"
    ("eval" body line 1)
    invoked from within
"eval [concat [list $proc] $args]"
    (procedure "ad_run_scheduled_proc" line 43)
    invoked from within
"ad_run_scheduled_proc {f f 30 search_indexer {} 1033473296 0 t}"
Debug: db_qd_get_fullname: following query in file: packages.acs-tcl.tcl.request-processor-procs proc: root_of_host
Collapse
Posted by defunct defunct on
I amy be missing something *really* simple, but surely tis entirely possible to have more than one package_id for a package_key??

In which casxe you shouldn;t be using db_0or1row... but db-multirow

Collapse
Posted by Tilmann Singer on
Did you also delete the package instance after unmounting, from Sitemap -> "Unmounted Applications"? If not please try that (and cross your fingers that it works ...)
Collapse
Posted by Jeff Davis on
This call is useful for things like the search_indexer since there
is no ad_conn in a scheduled procedure
but in almost all other cases people should be using
[ad_conn package_id].

It throws an error if there are more than one package_id for a
given key since it should only be used for singletons -- maybe the query should explicitly check that and throw a more descriptive error.
It definitely not pick one of several at random!

In any case, I will add something to the proc docs to this effect.

Collapse
Posted by Ola Hansson on
Hi H,

Deleting the package instance from Sitemap -> "Unmounted Applications" will not work. (At least it did not work for me).

What worked was to delete ALL News instances (and eventual customized code - so save a copy of it if this is the case). To do this, go to /acs-admin/apm/, click on one of the News links in the table of packages and on the next page click on the "Delete this package from your system" link at the bottom. But be very careful (as is stated loud and clear) as this will delete packages/news from your disk.

Collapse
Posted by H. shefaat on
Hi Ola, I think you are right. It did work to me. Instaed I use "Lars Blogger". It woks fine. Deleting the Packeges did not work! It occurs also an error If I try to delete the news module...very strange...
Collapse
Posted by Ola Hansson on
For a package like (for instance) ACS Developer Support that has got a "widget" which needs to be shown in the footer of many pages, be it you're requesting / or /forums/ or /ds/, it's kind of necessery, I suppose, to use a proc such as apm_package_id_from_key. The _from_key part suggests that only one value will be returned since a package key is unique - in this case the package_id of the one and only instance that can (or should) be mounted. Why must we use apm_package_id_from_key? Because we must get the package_id of DS even if we are visiting /news. Using ad_conn package_id would return the package_id of the visited news instance...

Using apm_package_id_from_key has the sad consequence that the package is doomed to be a singleton (that is it can only be mounted once (per sub-site)).

I am right in saying it can be mounted in another sub-site, ain't I?

A "regular" package, OTOH, that can make use of [ad_conn package_id] (because its scripts are always requested from inside its own package_id node) benefits from the possibility to be a non singleton and a "package aware" package.

Hmmm. This rant has too many commas, parenthesis and doublequotes... Oh well.😉

And please correct me if I am wrong!

Collapse
Posted by Jeff Davis on
Ola, that is pretty much right on the money.

Unfortunately there are a number of bad examples in the code now where apm_package_id_from_key should not have been used. Clickthrough for example can be mounted multiple times but this line:

ad_schedule_proc [ad_parameter -package_id [apm_package_id_from_key clickthrough] CacheSweeperInterval] clickthrough_cache_sweeper
just won't (and shouldn't) work if more than one instance is mounted.

The problem (and it is a shortcoming in the parameter system I think) is that you cannot have a parameter which is global to all instances of a package. I am not sure what the right answer on this is other than (in this example) splitting ct into a singleton clickthrough-service and an application clickthrough which depends on clickthrough-service.

Collapse
Posted by Lars Pind on
I was thinking about some changes:

1) Providing a canonical URL for packages so that you don't have to mount them if all you want is to get access to their "library" pages, like developer-support. Example: /packages/(package_key).

2) Extend this scheme so that /some/url/ref/package_key/somepage serves up pages from another package. The point would be to let you reference, say, the permissions pages, or the notification-request page, without URL-wise having to leave the package/subsite you're in. I'm not sure this is the right solution.

3) Make apm_package_id_from_key return the _first_ package instance if there's more than one, instead of erroring out. That makes it okay to use this when you don't really care which one you get. Notifications, for example. (Save for permissions issues, of course. Hm.)

/Lars

Collapse
Posted by Jeff Davis on
1.

I think there should be a single step install/enable/mount a set of packages for some common configurations but I would stop short of mounting them all that way (or doing it by default). I think you want to keep the url space clean and there are just too many packages of varying quality to trust that they will all be free of security holes and be functional. I think something like the checklist at packages-install for mounting at cannonical locations would be the most desirable way to do it (in fact adding a "Mount" checkbox to do this on that page might in fact be the right thing to do).

2.

Again, I think this is not such a good idea. Partly because of the same set of concerns raised above and partly because I think the right answer is to make everything subsite aware and having a half measure like you are talking about will just forestall fixing all the things which are currently broken with respect to subsiting.

3.

I looked through how the apm_package_id_from_key was being used and in most cases where I saw two package_id's could be returned it was indicative if something wrong with the package (or in the case of clickthroughs, a shortcoming with our handling of parameters). I would be more inclined to error out if you called this for a non-singleton package just so what I see as a pretty common error.

All this exacerbated by the fact that if you type package_id into the api-browser you will see:

bulk_mail::package_id 
        which works the way you are talking about, and 
        bulkmail is not a singleton but the proc is never 
        called.
rss_package_id
        singleton
notification::email::get_package_id 
        singleton
spam_package_id 
        singleton although the query handles multiple instances
email_handler_package_id 
        singleton
all pretty much unneccessary, and also a number more queries embeded in other procs all doing things in a haphazard fashion.

So assume you make this change...what happens is people go on their way and use apm_package_id_from_key since it just seems easier than doing things the right way (or worse they don't even realize this is not the right way) and then they start complaining about parameters not being recognized as being changed, permissions being broken, and other badisms (like things ending up in the wrong folders or under the wrong subsite).

All not good.

better to add a check constraint on apm_packages to prevent creation of more than one instance of a singleton and stricter handling in apm_package_id_from_key and fix the few bugs that manifest as a consequence.