Forum OpenACS Development: Minor Error in Calendar after upgrading

Request notifications

Hi

I had a minor error in calendar package in my upgrade. Perhaps it is a problem with some upgrade script that didn't load (not in kernel package). I don't know.

Some data to check the problem:

- In package/calendar/www/cal-item-new

--- Error Log ---

[18/Nov/2013:15:59:06][2076.153182208][-default:0-] Error: Ns_PgExec: result status: 7 message: ERROR:  missing FROM-clause entry for table "timespan_seq"
LINE 1: select timespan_seq.nextval from dual
^
QUERY: select timespan_seq.nextval from dual
CONTEXT: PL/pgSQL function time_interval__new(timestamp with time zone,timestamp with time zone) line 7 at SQL statement
PL/pgSQL function timespan__new(timestamp with time zone,timestamp with time zone) line 12 at RETURN

[18/Nov/2013:15:59:06][2076.153182208][-default:0-] Notice: -- creating per thread sequence table
[18/Nov/2013:15:59:06][2076.153182208][-default:0-] Error: POST http://localhost/despacho/agenda/cal-item-new?
referred by "https://localhost/despacho/agenda/cal-item-new?start%5ftime=7&date=2013%2d11%2d18"
Database operation "0or1row" failed
(exception ERROR, "ERROR: missing FROM-clause entry for table "timespan_seq"
LINE 1: select timespan_seq.nextval from dual
^
QUERY: select timespan_seq.nextval from dual
CONTEXT: PL/pgSQL function time_interval__new(timestamp with time zone,timestamp with time zone) line 7 at SQL statement
PL/pgSQL function timespan__new(timestamp with time zone,timestamp with time zone) line 12 at RETURN
")

while executing
"ns_pg_bind 0or1row nsdb0 {
select timespan__new (
:start_date::timestamptz,
:end_date::timestamptz
)

}"
("uplevel" body line 1)
invoked from within

--- DB output ---

openacs=# \df+ time_interval__new
\df+ time_interval__new
List of functions
-[ RECORD 1 ]-------+-----------------------------------------------------------------
Schema | public
Name | time_interval__new
Result data type | integer
Argument data types | timestamp with time zone, timestamp with time zone
Type | normal
Security | invoker
Volatility | volatile
Owner | openacs
Language | plpgsql
Source code | -- time_intervals.interval_id%TYPE
| declare
| new__start_date alias for $1; -- default null,
| new__end_date alias for $2; -- default null
| v_interval_id time_intervals.interval_id%TYPE;
| begin
| select timespan_seq.nextval into v_interval_id from dual;
|
| insert into time_intervals
| (interval_id, start_date, end_date)
| values
| (v_interval_id, new__start_date, new__end_date);
|
| return v_interval_id;
|
| end;
Description |

openacs=#

Collapse
Posted by Gustaf Neumann on
Dear Cesareo,

Are you using the recent version of acs-events (e.g. from the oacs-5-8 branch)? Did you upgrade this package?
This problem was fixed by victor in Nov 2010:

http://cvs.openacs.org/browse/OpenACS/openacs-4/packages/acs-events/sql/postgresql/upgrade/upgrade-0.6d3-0.6d4.sql?r=1.2

-g

Collapse
Posted by Cesareo Garci­a Rodicio on
Hi Gustaf!

Apparently, I've thought so :-) but upgrade scripts didn't load. Now I have just run them manually and it worked

It seems to be same problem.

Thanks Again

Collapse
Posted by Gustaf Neumann on
Good.... but still wondering, what version you see in /acs-admin/apm/ for acs-events?

Once again, it would have been nice to have a log in the database, what upgrade scripts were running correctly, and which are still outstanding.

-g

Collapse
Posted by Cesareo Garci­a Rodicio on
acs-events Events 0.6d5 (I'd already download last version).

Yes, as you have summarized a log audit of upgrade process would be great. Problem (at least for me) is to make sure that upgrade process goes in right order. As I understand, once it stops, it stops (don't load later versions of upgrade scripts)

Good news is that the solution is easy and working well: upgrade manual (psql -f) and IN ORDER. As I understand, I can upgrade several times so it doesn't happen anything wrong if I "repeat" some upgrade

Collapse
Posted by Gustaf Neumann on
When one of the upgrade scripts fails, OpenACS should not increase the version number; in your case, you have the most recent version number.

If you would have still an old version number in the database, re-running the sql upgrade scripts in the right order would happen automatically on a second upgrade attempt (in most cases, this is safe).

Collapse
Posted by Cesareo Garci­a Rodicio on
Something should be wrong with my upgrade process, I didn't mean of any big problem.

Anyway, as we said before, an audit upgrade sript logtable might solve this (perhaps) rare problem