Forum OpenACS Development: Re: Error sourcing xowiki-procs.tcl: invalid command name "attribute::exists_p"

i am not sure, what the last sentence means.

what is your exact installation order? Are local modifications involved? Check your error.log, whether packages/acs-subsite/tcl/attribute-procs.tcl is sourced before xowiki/tcl/xowiki-procs.tcl

Btw, the head versions of xotcl-core and xowiki do not use attribute::exists_p, therefore the the problem won't exist there. These versions are close to finishing for the oacs-5-4-compat stable release.

Thanks Gustaf, I have installed from head and they work after solving two problems.

I had two errors:

- New Install of xowiki 0.89 show error of get_root_folder when I go to new page http://server......com/xowiki/?object%5ftype=%3a%3axowiki%3a%3aPage&edit%2dnew=1&autoname=0

I executed fs::new_root_folder -package_id $xowiki_package_id and it work now.

- Upgrading from xowiki 0.60.4 return this error:

nsoracle.c:3904:ora_tcl_command: error in `OCIStmtExecute ()': ORA-00904: "PAGE_ORDER": invalid identifier

SQL: insert into xowiki_objecti (creation_user !>>>!page_order,creator,ppage_id,page_id,object_id,description,xowiki_object_id,nls_language,mime_type,title,item_id,revision_id) values (:creation_user,:page_order,:creator,:ppage_id,:page_id,:object_id,:description,:xowiki_object_id,:nls_language,:mime_type,:title,:item_id,:revision_id)
while executing
"ns_ora dml nsdb0 {insert into xowiki_objecti (creation_user,page_order,creator,ppage_id,page_id,object_id,description,xowiki_object_id,nls_language,mi..."
("uplevel" body line 1)
invoked from within
"uplevel $ulevel [list ns_ora $type $db $sql] $args"
("oracle" arm line 2)
invoked from within
"switch $driverkey {
oracle {
return [uplevel $ulevel [list ns_ora $type $db $sql] $args]
}
..."
invoked from within
"db_exec dml nsdb0 dbqd.::xo::db::CrItem-save_new.revision_add {insert into xowiki_objecti (creation_user,page_order,creator,ppage_id,page_id,object_id..."
("eval" body line 1)
invoked from within
"eval [list db_exec $command $db $full_statement_name $sql] $lob_argv"
invoked from within
"if { $lob_argc == 1 } {
# Bind :1, :2, ..., :n as LOBs (where n = [llength $lob_argv])
set bind_vars [list]
..."
("uplevel" body line 2)
invoked from within
"uplevel 1 $code_block "
invoked from within
"db_with_handle -dbn $dbn db {
if { $lob_argc == 1 } {
# Bind :1, :2, ..., :n as LOBs (where n = [llength $lob_argv])
..."
(procedure "db_dml" line 56)
invoked from within
"$insert_view_operation [my qn revision_add] [[my info class] insert_statement $__atts $__vars]"
("uplevel" body line 21)
invoked from within
"uplevel 1 $transaction_code "
(procedure "db_transaction" line 1)
invoked from within
"db_transaction {
$__class instvar storage_type object_type
[self class] lock acs_objects "SHARE ROW EXCLUSIVE"
set revision_id [db_n..."
(procedure "save_new" line 30)
invoked from within
"next"
(procedure "save_new" line 4)
invoked from within
"next"
(procedure "save_new" line 3)
::3115 ::xo::db::CrCache::Item->save_new
invoked from within
"::$folder_id save_new"
(procedure "require_folder_object" line 36)
::3093 ::xowiki::Package->require_folder_object
invoked from within
"my require_folder_object"
(procedure "init" line 5)
::3093 ::xowiki::Package->init
::xowiki::Package ::xotcl::Class->create
invoked from within
"my create ::$package_id"
(procedure "require" line 10)
::xowiki::Package ::xo::PackageMgr->require
invoked from within
"my require -url $url $package_id"
(procedure "initialize" line 26)
::xowiki::Package ::xo::PackageMgr->initialize
invoked from within
"::xowiki::Package initialize -package_id $package_id -init_url false"
(procedure "::xowiki::upgrade_callback" line 235)
invoked from within
"::xowiki::upgrade_callback -from_version_name 0.60.4 -to_version_name 0.89"
("eval" body line 1)
invoked from within
"eval $command"
(procedure "apm_invoke_callback_proc" line 37)
invoked from within
"apm_invoke_callback_proc -version_id $version_id -type after-upgrade -arg_list [list from_version_name $upgrade_from_version_name to_version_name $ver..."
(procedure "apm_package_install" line 191)
invoked from within
"apm_package_install -enable -package_path $package_path -load_data_model -data_model_files $data_model_files $spec_file"
("foreach" body line 52)
invoked from within
"foreach package_key $install {
ns_log Notice "Installing $package_key"

array unset version
array set version $repository($package_key..."
("uplevel" body line 49)
invoked from within
"uplevel {
ad_page_contract {
Install packages -- actual installation

@param install Tcl list of packages to install in the order in which the..."
(procedure "code::tcl::/web/devoei/packages/acs-admin/www/install/instal..." line 2)
invoked from within
"code::tcl::$__adp_stub"
invoked from within
"if { [file exists $__adp_stub.tcl] } {

# ensure that data source preparation procedure exists and is up-to-date
adp_init tcl $__adp_stub
..."
("uplevel" body line 3)
invoked from within
"uplevel {

if { [file exists $__adp_stub.tcl] } {

# ensure that data source preparation procedure exists and is up-to-date
adp_init t..."
(procedure "adp_prepare" line 2)
invoked from within
"adp_prepare"
invoked from within
"template::adp_parse [file root [ad_conn file]] {}"
(procedure "adp_parse_ad_conn_file" line 5)
invoked from within
"$handler"
("uplevel" body line 2)
invoked from within
"uplevel $code"
invoked from within
"ad_try {
$handler
} ad_script_abort val {
# do nothing
}"
invoked from within
"rp_serve_concrete_file [ad_conn file]"
(procedure "rp_serve_abstract_file" line 60)
invoked from within
"rp_serve_abstract_file "$root/$path""
("uplevel" body line 2)
invoked from within
"uplevel $code"
invoked from within
"ad_try {
rp_serve_abstract_file "$root/$path"
set tcl_url2file([ad_conn url]) [ad_conn file]
set tcl_url2path_info..."

I had executed from /ds/shell ::xowiki::update_views, ::xowiki::upgrade_callback -from_version_name 0.60.4 -to_version_name 0.89 and fs::new_root_folder -package_id $xowiki_package_id. it work now.

Concerning new installs:
The creation of the folder should happen automatically, this worked on Oracle before and should be easy to fix. i have never used ::fs::new_root_folder and nobody is supposed to use it. Furthermore, you are asking for troubles by bypassing e.g. the xowiki naming conventions.

Since i have no oracle around to play with a from-scratch installations, can i ask to check the error messages during new installations in more detail?

Concerning upgrade:
the support for page_order in Oracle is relatively new (form march this year). Upgrading is not tested by many, although it worked for viaro. I am less concerned about this one than the first problem; actually, the problems might boil down to a common problem.

I want xowiki to work as front page of a .LRN site but not necessarily inside communities.

I get this error when I click on "New Page":

oracle.c:3542:ora_tcl_command: error in `OCIStmtExecute ()': Error - OCI_NO_DATA
SQL:
begin
:1 := file_storage.get_root_folder(
package_id => :package_id
);
end;

while executing
"ns_ora exec_plsql_bind nsdb0 {
begin
:1 := file_storage.get_root_folder(
package_id => :package_id

....

Please, forget what I said about fs:new_root_folder.

I think that the problem is about getting the "fs_folder_id" with an empty "community_id" in ::xowiki::Page instproc edit when .LRN is installed:

set fs_folder_id ""
if {[info commands ::dotlrn_fs::get_community_shared_folder] ne ""} {
set fs_folder_id [::dotlrn_fs::get_community_shared_folder -community_id [::dotlrn_community::get_community_id]]
}

Maybe, this can be fixed inserting "xowiki package_id" and its "folder_id" in "fs_root_folders" table when xowiki is mounted not inside dotlrn.
Or maybe, adding another condition to the last "if" to check if "dotlrn" mounting point is in the url.

i have now tried an installation of dotlrn 2.3.1 + xowiki used outside of a community (as you sketched) in postgres, everything works as expected.

The problem appears to be different semantics in the OpenACS and Oracle versions of [fs::get_root_folder], when it is called with a package_id having no root folder. In PostgresSQL fs::get_root_folder -package_id 123 returns empty, while oracle throws apparently the error above.

I fixed the problem the easy way (in xowiki), a better fix would be to make the Postgres and Oracle versions of fs::get_root_folder to behave identical.

Best regards
-gustaf neumann

Thanks a lot Gustaf.

I upgraded xowiki with your change and it works correctly.

I will install xowiki version for dotlrn 2.3.1 on oracle,I will test the upgrade to 0.90. I will post the result of this with logs.

I think that the problem with fs::get_root_folder is complicado to fix because I think that it's no only for this function. I will post it to try fix it

Sorry replace complicato with complicated.

I think that the problem with fs::get_root_folder is complicated to fix because I think that it's no only for this function. I will post it to try fix it