World: r3wp

trying 0.9.12 and getting this crash:


        URL  = /bugs/
        File = /home/henrikmk/serve/www/bugs/head.rsp

        ** Script Error : Invalid path value: locals 
        ** Where: repend 
        ** Near:  [request/config/locals/instance 
%title.inc

This is with the latest cheyenne release 0.9.20.

Have you followed the migration process? There's a migration script 
in the archive, probably in the /private folder.

It's the %private/upgrade-096-0910.r script.

I see, will try.

There doesn't seem to be such a script. There is however an install.r 
script.

About your error, the newest CureCode versions require the definition 
of a LOCALS block in the webapp:

	locals [
		name		"REBOL3 Tracker"
		instance	%rebol3/
		short		"r3"
	]

private$ ls

ChangeLog.txt     build-db.sql   generate-load.r  helper.r   instances
access-control.r  db-abstract.r  generate-test.r  install.r

I see, thanks.

ok, it looks like I'm going to need that upgrade script. where can 
I find it? it's not included in the distribution.

http://curecode.org/dl/upgrade-096-0910.zip


I am not sure it applies to 0.9.8, you'll need to check if the new 
SQL  tables are already there or not.

Be sure to backup your database before using it.

ok, thanks.

now I get an invalid port spec:

** Access Error : Invalid port spec: mysql://<removed>
        ** Where: do-sql
        ** Near:  [do-sql/flat 'bugs any [

You should check that <removed> part for an invalid definition.

It should be something like this:

mysql://user:[pass-:-localhost]/bugs


I also tried it in a different console and it only appears if the 
mysql-protocol is not loaded.

There is no reference to mysql-protocol.r anywhere in the source 
code. Could that be it?

In 0.9.8 there is a reference to mysql-protocol.r in app-init.r, 
but it's gone in 0.9.12.

Ah probably, now CureCode expects that the %mysql-protocol.r be loaded 
externally. The best way to do that is to instruct Cheyenne to load 
it directly by declaring it in the GLOBALS section of the config 
file, like this:

	worker-libs [
		%<path-to-mysql-protocol-folder>/mysql-protocol.r
	]

I see.

Btw, all these setup steps are handled by the %private/install.r 
when doing a new installation.

actually no, I already read through the install.r file and there 
is no reference to anything but SQL queries and a message which contains 
a description of the webapp, but not worker-libs.

You're right, it is missing, I'm adding it right now.

Another crash in index.rsp:

sess: session/content

	if all [
		not sess/login?
		none? validate/full [action word! *]
		'identify = request/content/action
	][

SESS appears to be NONE.

Have you restarted Cheyenne fully after the changes in httpd.cfg?

I kill the old session with kill -9 and start the new after that

You should stop Cheyenne completly, remove the %.rsp-sessions file 
found in Cheyenne working folder, then restart it.

ls -lR | grep sessions

reveals no such file

Try with ls -laR | grep sessions while Cheyenne is fully stopped.

It's a file starting with a dot (= hidden file), so -lR is not enough 
to list it. Also, it exists only when Cheyenne is not running.

where is the worker-libs block supposed to be located?

GLOBALS section of %httpd.cfg

that seemed to be it. now I'm back to this morning's crash when clicking 
bug entries in the database.

ok, missing table...

The upgrading script should have created all required tables.

it did not. there was a large number of errors, since there were 
no checks if the tables were actually existing or not and I couldn't 
tell whether the upgrade script actually finished.

As I said, the script is for v0.9.6, for your v0.9.8, you should 
have checked manually which tables are already created. You should 
then comment the lines in the upgrade script to match your configuration.

I'm doing each part manually now.

the rss.gif image is missing from the img/ directory.

Thanks, I'm adding it to the online archive.

When logging in this line fails:

if sess/prefs/my-filter [sess/query: copy sess/prefs/my-filter]

The content of SESS/PREFS is:


[version 1 tickets-color-mode line tickets-alt-color #EEE default-project 
1]


I suppose this was meant to be stored in the database, but would 
a better check on this not be:


if select sess/prefs 'my-filter [sess/query: copy sess/prefs/my-filter]

?

I don't see anything about filters in the upgrade script.

Looking into that issue...

It should work okay with v0.9.12. It might be caused by an obsolete 
session object. You should follow the %.rsp-sessions suppression 
process once again.

Hmm, wait, I need to check the database content, it seems that the 
PREFS table might contain obsolete data that are not processed by 
the upgrade script.

Yes, I checked the db content and it contains the block I posted 
above.

You should delete the content of PREFS table, CureCode will recreate 
correct new data if no PREFS record is found:

    DELETE FROM prefs

(make a backup before)

I have test it locally, it should fix your upgrading issue.

ok, that works now.