Forum OpenACS Q&A: Re: xowiki install failed in new OpenACS install

Collapse
5: Re: xowiki install failed in new OpenACS install (response to 4)
Posted by Colin Charbonneau on 07/08/15 10:54 PM
Attempted install using HEAD codebase. Same result.

Could this be the version of postgresql that I'm using causing the issue?

Collapse
6: Re: xowiki install failed in new OpenACS install (response to 5)
Posted by Benjamin Brink on 07/09/15 12:57 AM
Hi Colin,

I noticed an error something like this awhile back when I tried using a fresh xowiki install. I haven't tested lately, but my limited experience with most all esoteric xowiki errors are overcome by:

1. restarting naviserver after an install and before doing anything else.

2. waiting an hour (or as much as a day) before using xowiki;

Explanation of #2: There are some critical background xowiki/pg related init processes started when xowiki is installed. Also, some xotcl/xowiki processes apparently return incomplete results if process time is too long. When I install on *very* slow/limited systems, some part of the background init appears to timeout ( and fail silently), subsequently resulting in esoteric errors. This is not necessarily an xowiki specific issue. One time about 14 years ago, something similar was happening to early openacs installations on vm installed in an overloaded server.

Hope that helps.

Collapse
7: Re: xowiki install failed in new OpenACS install (response to 5)
Posted by Gustaf Neumann on 07/09/15 06:25 PM
Dear Colin,

the postgres version is not the problem. The problem seems to be that in your installation, xowiki adds the column "title" to xowiki_page, leading later to duplicate columns. 

[07/Jul/2015:11:55:18][48366.7fc22953f700][-conn:openacs:0-] Notice: xodb: adding column <alter table xowiki_page add column description  text >
[07/Jul/2015:11:55:18][48366.7fc22953f700][-conn:openacs:0-] Notice: xodb: adding column <alter table xowiki_page add column publish_date  timestamp with time zone >
[07/Jul/2015:11:55:18][48366.7fc22953f700][-conn:openacs:0-] Notice: xodb: adding column <alter table xowiki_page add column title  varchar(1000) >

When one adds the following line 

--- xotcl-core/tcl/05-db-procs.tcl	30 Jun 2015 09:20:54 -0000	1.102
+++ xotcl-core/tcl/05-db-procs.tcl	9 Jul 2015 15:10:16 -0000
@@ -706,6 +706,7 @@
   }
 
   require proc table {name definition {populate ""}} {
+    my log "==== require table $name exists: [my exists_table $name]\n$definition"
     if {![my exists_table $name]} {
       set lines {}
       foreach col [dict keys $definition] {lappend lines "$col [dict get $definition $col]"}
one should see at startup 
[09/Jul/2015:10:12:07][83047.7fff7bd72300][-main-] Notice: ==== require table xowiki_page exists: 1
page_order { ltree DEFAULT '' } creator { text } page_id { integer REFERENCES cr_revisions(revision_id) ON DELETE CASCADE
        CONSTRAINT xowiki_page_page_id_pk PRIMARY KEY }, ::xo::db::require ->table (0ms, 11ms)
The values are pairs with attribute_names and definitions. Probably, on your site you get "text", "publish_date" and "title" as well.... but why?

hmm... i found something incorrect: a cached value might lead to incorrect results, returning "title" in the table definition - but that should not happen during installs/loading. Do you have some local modification affecting the loading order?

Please try the change below, it should work with oacs-5-8 and the HEAD version. AFIKT, thus change causes no harm. Currently, i am on the move in Mexico (vacation), but i will commit this when possible.

best regards
-gn 

--- xotcl-core/tcl/01-debug-procs.tcl	15 Jun 2015 19:28:33 -0000	1.76
+++ xotcl-core/tcl/01-debug-procs.tcl	9 Jul 2015 16:08:54 -0000
@@ -967,7 +967,8 @@
   set newSlot [self]::slot::$name
 
   $slot copy $newSlot
-  $newSlot configure -domain [self] -manager $newSlot -create_acs_attribute false {*}$config
+  $newSlot configure -domain [self] -manager $newSlot -create_acs_attribute false -create_table_attribute false {*}$config
+  my set db_slot($name) $newSlot 
 }
Collapse
8: Re: xowiki install failed in new OpenACS install (response to 7)
Posted by Colin Charbonneau on 07/09/15 08:31 PM
I attempted the change at the bottom of your post, but it did not seem to be the cause of my problems. I am doing to drop the DB and re-install again, and try the extra log entry to see what I receive from it.
Collapse
9: Re: xowiki install failed in new OpenACS install (response to 7)
Posted by Colin Charbonneau on 07/09/15 10:02 PM
Adding this log message did not seem to make any significant impact on startup... it does not seem to be getting reached.
Collapse
10: Re: xowiki install failed in new OpenACS install (response to 9)
Posted by Gustaf Neumann on 07/09/15 11:45 PM
the code leading to the problem checks, if the table has the desired columns, and adds if it these are not there. So, when your database has already the columns "description", "publish_date" and "title" defined for table "xowiki_page", then the problem persists.

If it is a fresh db, i would recommend to drop the db and install new. Otherwise, drop the mentioned columns from "xowiki_page", do a "drop view xowiki_pagei CASCADE" and restart. With the mentioned changes, xowiki will heal itself.

This code in "require table" will be definitely executed, since this is the only place where "alter table ... add column" is executed (as shown from your install error.log). Can it be that you have multiple xotcl-core* directories under packages and you have modified the wrong instance?

I've added the mentioned change to cvs HEAD an to the oacs-5-8 branch. After the next generation of the APM files this night (middle-european time) the change is as well in the .apm file in the OpenACS repository.

-g

Collapse
11: Re: xowiki install failed in new OpenACS install (response to 10)
Posted by Colin Charbonneau on 07/10/15 04:04 PM
You're right. OpenACS was loading the wrong code after I'd made the change. This seems to work now.

Thanks for your help, especially while on vacation.

Collapse
12: Re: xowiki install failed in new OpenACS install (response to 11)
Posted by Gustaf Neumann on 07/10/15 05:19 PM
Glad, that it helped! -g