Forum OpenACS Q&A: News and PG7.2 Working?

Collapse
Posted by Raul Rodriguez on

On my RH7.2/PG7.2/OACS4.5b install I mounted news. After entering 1 test news item and selecting the default archieve date, I clicked on administration. I got the following error:

Database operation "select" failed (exception NSDB, "Query was not a 
statement returning rows.")
         while executing
     "ns_pg_bind select nsdb0 {
           
     select
         item_id,
         content_item__get_best_revision(item_id) as revision_id,
         content_revision__get_number(new..."
         ("uplevel" body line 1)
         invoked from within
     "uplevel $ulevel [list ns_pg_bind $type $db $sql"
         invoked from within
     "db_exec select $db $full_statement_name $sql"
         invoked from within
     "set selection [db_exec select $db $full_statement_name $sql]"
         ("uplevel" body line 2)
         invoked from within
     "uplevel 1 $code_block "
         invoked from within
     "db_with_handle db {
             set selection [db_exec select $db $full_statement_name 
$sql]

             while { [db_getrow $db $selection] } {
                 if { [empty_string_p $..."
         (procedure "db_multirow" line 39)
         invoked from within
     "db_multirow news_items itemlist "
     select
         item_id,
         content_item.get_best_revision(item_id) as revision_id,
         content_revision.get_number(news..."
         ("uplevel" body line 66)
         invoked from within
     "uplevel {
               # /packages/news/www/admin/index.tcl
...

After looking more into it, the problem seems to have come from news__status. PG7.2 appears to have a problem with the combination of extract and interval. This is the else clause from news__status it was trying to evaluate

else
    if v_archive_date - current_timestamp > 0 then
         return ''published, archived in ''
         || text(round(extract(days from interval (v_archive_date - 
current_timestamp))
         + extract(hours from interval (v_archive_date - 
current_timestamp))/24,1))
                     || '' days'';
...

I tested interval(foodate - bardate) on PG7.1.3 and it returned something on the lines of "number days time". When I tried it on PG7.2 I got "number". Therefore it appeas as if PG7.2 does not extract "days" from the interval because interval does not return something with "days" in it. Has anyone else experience this or am I missing something?

Collapse
Posted by Michael Bluett on
Collapse
Posted by Robert Locke on
Hi Raul,

That hairy "text/round/extract/interval" call was the only way I could match the corresponding Oracle query exactly when I did the port.

I don't have access to a 7.2 installation, so I'm not sure what's the best way to help.  Have you managed to solve the problem?

Collapse
Posted by Louis Zirkel on
Raul,

I have experienced the same problem that you explained previously and I found that when using PG7.2 I could resolve the problem by simply removing an reference to "interval" from the offending file. I don't know what has broken or been changed in PG7.2 from PG7.1.3, but in this instance it completely broke that query.

Here is the code you've listed above that I've replaced. Basically anywhere that an interval is used, I've removed the reference to the interval keyword.


    else
        if v_archive_date > current_timestamp  then
            return ''published, archived in ''
            || text(round(extract(days from (v_archive_date -              
                    current_timestamp)) + extract(hours from         
                    (v_archive_date - current_timestamp))/24,1))
            || '' days'';

I've got a seperate file that redefines the entire news__status stored proc if you'd like me to send you a copy.

Collapse
Posted by Robert Locke on
Seems like the interval keyword isn't required for PG7.1.3 either.

So, I removed it, tested the change, and committed the fix to CVS.

Collapse
Posted by Don Baccus on
Ouch - remember ... bug fixes to the OpenACS 4.5 branch, new development to the default branch!

I'll move your fix over but in general we need fixes intended to go into 4.5 to be put in that branch.

I'm doing my merges from 4.5->devel not the other way 'round (otherwise changes not meant to go in 4.5 would land there when I merge).

I'll post a heads-up reminder ... I mentioned this when I branched the tree but it was buried in other comments.