Forum OpenACS Development: acs-message,acs-mail status report.

Posted by Jon Griffin on 05/12/01 07:23 AM

I have almost completed the port of acs-message.
One problem that came up is PG's lack of sufficient PL/pgSQL parameters. I need 17 and the default is 16. I am trying to find a solution (like deleting one parameter) but I won't be able to get to it for a day or so.

I will have the Oracle version ported by tomorrow night (Saturday) if my client call tomorrow doesn't take all day. I am almost done with it anyway so it just needs a couple of query tweaks and it will be ready.

I am doing a 100% complete port at this time, nothing new and hopefully nothing taken away. I still feel that some of this stuff will need to be changed as it has a lot of redundancy and that is plain wrong.

acs-mail will be next (probably before I finish the PG port of messages) and also will be a straight port. I checked and there might be a couple of non-pg supported constructs I may have to work around also.

The bottom line, anyone depending on acs-messaging or acs-mail can expect a straight port. Anyone that is writing new modules would be wise to not depend on the functionallity being the same for the future.

2: Response to acs-message,acs-mail status report. (response to 1)

Posted by Talli Somekh on 05/12/01 07:33 AM

Thanks alot Jon. I appreciate that you've kept us aware of your porting strategy and listened to the community's response. Looking forward to your suggested improvements for these modules.

talli

3: Response to acs-message,acs-mail status report. (response to 1)

Posted by Don Baccus on 05/12/01 03:12 PM

Jon, if you want we can probably get you some spare cycles to help with the PG side. Sounds like you're pretty busy ...

Thanks for the update. I agree that we still want to work on improving/fixing (take your choice) these, in particular removing the overlap and redundancy that's there. A straight port will get us on the move for now, though.

4: Response to acs-message,acs-mail status report. (response to 1)

Posted by Jon Griffin on 05/14/01 06:36 PM

I checked the Oracle versions into CVS and am half way thru the PG versions.

I have to convert a lot of blobs in acs-mail and still have the too many args problem in acs-messaging.

5: Response to acs-message,acs-mail status report. (response to 1)

Posted by Jon Griffin on 05/15/01 06:15 PM

acs-mail is checked in and almost ready for testing

There is only one function, acs_mail_body__new, which uses utl_inaddr.get_host_name. I need to find a replacement for this.

Anyone wanting to test it is welcome as I am likely not going to have any time due to the pending birth of my first child!.

Please use the SDM to report any problems.

6: Response to acs-message,acs-mail status report. (response to 1)

Posted by Jon Griffin on 05/15/01 08:43 PM

All that proc does is get the hostname of the local machine if none is given.

I have a couple of options.

Make that parameter mandatory. ( I don't know if this is possible in pgplsql).
Extend plplsql with this functionality. (Simple C program or even calling the OS)
Find a way to use [ns_conn host], again I don't know how to do this in pgplsql.

Any suggestions are appreciated.

7: Response to acs-message,acs-mail status report. (response to 1)

Posted by Don Baccus on 05/15/01 10:03 PM

How often is it called? If not often, I suggest making it mandatory. You can do that by doing something like:

if parameter is null then
raise error "hey dummy, don''t do this!"
end if;

You can then pass it in from the Tcl environment ...

C functions are problematic as you can't just do a "create function" and be done. The C function needs to be compiled, linked, and installed separately. This is a pain in an environment where we want the APM to do everything necessary to install a package.

8: Response to acs-message,acs-mail status report. (response to 1)

Posted by Jon Griffin on 05/16/01 12:20 AM

Along those lines, what are we to do with the default values that pgplsql can't use? I notice that using if/else we could assign in the body but this seems very ugly.

9: Response to acs-message,acs-mail status report. (response to 1)

Posted by Don Baccus on 05/16/01 02:12 AM

We've been supplying the default values in the call. If there are cases where very few calls override a default value, consider making an instance of the function that drops the parameter and uses the default.

Postgres supports function overloading so one can, with care, supply a handful of overloaded variants that have the same name. For functions that aren't often used I suppose the "defaultified" version could just call the full version, but for those that get heavy traffic code duplication is probably a better solution.

10: Response to acs-message,acs-mail status report. (response to 1)

Posted by Jon Griffin on 05/16/01 02:33 AM

Can you give me a file that has been ported that does this. I am lazy!

11: Response to acs-message,acs-mail status report. (response to 1)

Posted by Steve Woodcock on 05/16/01 09:54 AM

Have a look at acs_object__new in acs-kernel/sql/postgresql/acs-objects-create.sql. There's a full six arg version, followed by a shorter two arg one.

12: Response to acs-message,acs-mail status report. (response to 1)

Posted by Domingo Alvarez duarte on 05/17/01 11:08 AM

Sorry but when you say acs-message are you refering to acs-messaging ?
If so I can't see any change in the cvs tree .

13: Response to acs-message,acs-mail status report. (response to 1)

Posted by Jon Griffin on 05/17/01 06:29 PM

acs-messaging

14: Response to acs-message,acs-mail status report. (response to 1)

Posted by Jon Griffin on 05/23/01 08:08 AM

I just checked in the mostly complete acs-mail and acs-messaging packages.

NOTE There are still a couple of questions and problems. It is there for the porters who need to know what the pl/sql will be. I had to make some changes and they are noted in the source.

I will make a formal change doc when I am finished.

15: Response to acs-message,acs-mail status report. (response to 1)

Posted by Jon Griffin on 06/09/01 06:51 PM

acs-message is now complete except for one query which uses a connect by. I am not sure how to fix this in Postgres and probably won't really have time for it for a few days. Does anyone with experience converting connect by's have any thoughts?

acs-mail is also mostly complete, (i.e. Oracle should work fine) but there are a lot of blobs that will need to be converted to the Content Repository.

There were several API changes that had to be made and right now they are commented in the source only. When this is ready for release I will document them for real.

16: Response to acs-message,acs-mail status report. (response to 1)

Posted by Dan Wickstrom on 06/11/01 03:55 PM

There are two viable alternatives for porting connect-by statements, both of which are dicussed in this thread. So far we've only used the second option based on a variable length sortkey. The nested-set model which is also discussed in that thread works well, but insert/update performance will degrade as the table size grows.

Take a look what was done for acs_objects. You should be able to copy the triggers and modify them for your use in acs-messaging.

17: Response to acs-message,acs-mail status report. (response to 1)

Posted by Jon Griffin on 06/15/01 04:09 AM

I updated the cvs tree for acs-messages yesterday with some patches made by Vinod.
Other than the connect by it should be usable in PG.

18: Response to acs-message,acs-mail status report. (response to 1)

Posted by Luke Pond on 06/18/01 08:26 PM

The Musea team is working on the bboard port this week. The bboard package has 3 more connect by queries on the acs_messages table that need to be ported, plus the one that Jon left in acs_messaging.

I will follow Dan's example and add a tree_sortkey column to acs_messages in order to get these four queries to work in postgresql. Dan's already done this for both acs_objects and acs_object_types, so I expect it will work flawlessly. 😊

19: Response to acs-message,acs-mail status report. (response to 1)

Posted by Jon Griffin on 06/20/01 12:10 AM

Luke,
I won't bother with the connect by in messaging then. I am really busy anyway so if you could just let me know when you have it finished I will update my cvs.

Also, have you run a PG version yet to make sure the bugs are out? I know that Vinod was porting some Oracle PL/Sql mail procs to get rid of my ugly hack. I think reading the notes though you will come to the conclusion that what I took out wasn't necessary anyway.