Forum OpenACS Q&A: Re: Problem Installing The Jabber Package

Collapse
Posted by Bjoern Kiesbye on
Hi,

the problem isn't nsjabber, during header runs (compilation) I can not just define which SQL should be used (like openacs does it with .xql files) as well I can define which db_api call should be used (dml for oracle, Select for postgres). Even if nsjabber with postgress support doesn't run Bug free jet (because I changed some other things together with the  postgres port (db access)).

This problem  ocures in oacs only, do we have a flag which determines which db an oacs installation is using ?
I could then wrap the db calls into if statemnts (their are only a few which are not called often (only when a screen/conference_room object is droped)).

I've fixed some bugs in the jabber-create.sql

Hi Martin did you already wrote a jabber-drop.sql? If so could you upload it to the file storage, I will include it into the package then.

Collapse
Posted by martin hebrank on
Bjoern,
I've emailed you the jabber-drop.sql directly, if you don't get it, tell me.

It doesn't have to be decided at compile time. It can be decided at run time. In the config.tcl we're told to setup the jabber db pool like this:

ns_section "ns/db/pool/jabber"
ns_param driver postgres
...

We can use this ns_param like we do all others to decide if we're using oracle style SQL and DB calls or postgress. As I've listed it before it worked changing. If you're worried about speed, you can move the strcmp to happen once during configuration and then just use a simple boolean as the condition in the if (). Relative to the total work done, this would add no overhead.

If I get a little time today I'll make the changes and send them to you so you can see.

I do, however, have it working in AOLServer 4, OpenACS 5.1 and Postgres 7.3.4 (I should probably upgrade that), though I haven't checked the conference part, but since that's not what I'm very interested in at the moment I'm not going to bother with it yet.

** Martin