Forum OpenACS Development: cal_item_new doesn't exist inside dotlrn

Request notifications

After submitting form cal-item-new, the system returns an error. It doesn't find cal_item_new

The URL is https://iurix.com/dotlrn/clubs/calendariodebella/calendar/cal-item-new

i.e. /dotlrn/clubs/calendariodebella/calendar/cal-item-new

However, submitting the form/calendar/cal-item-new executes with no errors.

What would be the solution to make /dotlrn aware of calendar plsql functions?

Or would it be the other way around? (i.e. to make calendar already of multiple instances)

Database operation "0or1row" failed (exception ERROR, "ERROR: function cal_item__new(unknown, unknown, unknown, unknown, unknown, unknown, unknown, unknown, unknown, unknown, unknown, timestamp with time zone, unknown, unknown, unknown, unknown, unknown, unknown, unknown) does not exist
LINE 2: select cal_item__new (
^
HINT: No function matches the given name and argument types. You might need to add explicit type casts.
")

ERROR: function cal_item__new(unknown, unknown, unknown, unknown, unknown, unknown, unknown, unknown, unknown, unknown, unknown, timestamp with time zone, unknown, unknown, unknown, unknown, unknown, unknown, unknown) does not exist
LINE 2: select cal_item__new (
^
HINT: No function matches the given name and argument types. You might need to add explicit type casts.

while executing
"ns_pg_bind 0or1row nsdb0 {
select cal_item__new (
null,
:calendar_id,
:name,
null,
null,
..."
("uplevel" body line 1)
invoked from within
"uplevel $ulevel [list ns_pg_bind $type $db $sql]"
invoked from within
"db_exec 0or1row $db $full_statement_name $sql"
("uplevel" body line 8)
invoked from within
"uplevel 1 $code_block "
invoked from within
"db_with_handle -dbn $dbn db {
# plsql calls that are simple selects bypass the plpgsql
# mechanism for creating anonymous func..."
(procedure "::nsf::procs::db_exec_plsql" line 56)
invoked from within
"db_exec_plsql cal_item_add {}"
(procedure "::nsf::procs::calendar::item::new" line 38)
invoked from within
"calendar::item::new -start_date $start_date -end_date $end_date -name $title -description $description -location $location -related_link_url $re..."
("uplevel" body line 13)
invoked from within
"uplevel #$level $new_data"
(procedure "::nsf::procs::ad_form" line 690)
invoked from within
"ad_form -extend -name cal_item -validate {
{title {[string length $title] <= 4000}
"Title is too long"
}
{description {[string equ..."

Collapse
Posted by Gustaf Neumann on
Iuri,

i can't reproduce this on my instances. Does this happen with a fresh install from the oacs-5-10 branch?

In general uses the dotlrn calendar just the plain OpenACS calendar. So, when adding a calender item in a plain OpenACS calendar works for you, then i would assume local modification on your instance in the dotln calendar or some mixed installation with old package versions.

Collapse
Posted by Iuri Sampaio on
No. the installation is OACS 5.9.2d1. .LRN is 2.9.1

No local modification was made in those packages.

url="acs-kernel" version="5.9.2d1"/
url="dotlrn" version="2.9.1"
url="calendar" version="2.9.1"/
url="calendar-portlet" version="2.9.1"/>

Collapse
Posted by Antonio Pisano on
Dear Iuri,

I double checked your situation: I have installed a fresh instance from the 5.9.1 tarball, installed dotlrn and upgraded all packages from repositories to the last 5.9 branch versions avaliable, then I created a new community, joined it, entered the calendar UI and created a new event and the issue you described could not be reproduced.

Which Postgres version are you running? This might or might not have a role. Suggested Postgres version for 5.9.1 is at least 9.6[1]

Might help if you could provide steps to reproduce

Ciao

Antonio

[1] https://openacs.org/xowiki/openacs-compatibility-matrix

Collapse
Posted by Gustaf Neumann on
the version number matrix was not correct (i have tried to fix this now, editing this table is a pain)
- 5.9.1 requires at least PostgreSQL 9.2
- 5.10.0 will require at least PostgreSQL 9.4 when it is released

It was always the policy for an OpenACS release to run also with the oldest supported PostgreSQL version at this time (pg version before end-of-live). For OpenACS 5.10 this will be PostgreSQL 9.4.