Forum OpenACS Q&A: ACS approval of interoperability

Collapse
1: ACS approval of interoperability
Posted by Bob Powell on 06/04/03 03:46 PM
Could someone please explain to me at what point in time the ACS community recommends version specific upgrades.  Is there such a thing?

For instance, I want to use Postgres 7.3.3 and I'm using version 4.6 of ACS.  Is someone specifically testing this circumstance or does the community wait until someone just does it and lets the rest of the community know?

If there is some place to go on this site that contains that information?  Thanks.

Collapse
2: Re: ACS approval of interoperability (response to 1)
Posted by Don Baccus on 06/04/03 03:53 PM
What has happened in the past is that people volunteer to test things out for new versions and just let the community know the result.  Frequently the same people volunteer to fix any problems.  We have a similar situation with Oracle 9i and there are a couple of people who've volunteered to fix OpenACS so it works with 9i for the 5.0 version.  For PG, I and a couple of other people volunteered to make the necessary changes for 4.6.2.  Some things were missed, unfortunately, but I think 4.6.3 works quite well with PG 7.3.3.

However ... the toolkit's big and we don't have regression or coverage tests (both things I'd like to have happen in the next few months) so testing's a big job.

I've been using PG 7.3.2 for all my OpenACS development work for a few months now so I can say that the core and basic .LRN functionality work with 7.3.x just fine.

Collapse
3: Re: ACS approval of interoperability (response to 1)
Posted by Randy Ferrer on 06/04/03 11:14 PM

Don or anyone else familiar with PG innards:

Before I go off to upgrade my PG 7.3.2 installation to the new 7.3.3 release, does anyone have any idea whether the statement below from the PG folks, might point to any compatibility problems with OACS 4.6.3?

"This release [PG 7.3.3], as with all minor releases, does not *require* a dump/reload to be upgraded to, but there is a change to pg_proc, as pertains timestamptz_izone that only takes effect after an initdb ..."

Thanks!

Collapse
4: Re: ACS approval of interoperability (response to 1)
Posted by Don Baccus on 06/05/03 12:04 AM
Randy ... do you have any specifics on what that change is?  I  will cross my fingers and hope it doesn't impact us.  I wish this date/time stuff would just settle down and quit changing on us ...
Collapse
5: Re: ACS approval of interoperability (response to 1)
Posted by Randy Ferrer on 06/05/03 12:44 AM
No specifics but I'll dive into the docs right now and see if I can dig out anymore details. If I can't pull out anything else, I guess crossing fingers, legs and everything else that I can cross will be in order as I proceed to update my dev installation and test profusely. In any case, these changes are back patched from the upcoming 7.4 release to the 7.3 release. sigh.... If anyone knows anyone in the PG group, it might be helpful to ask if this latest change will affect us in any way... I'll post back one way or the other what I find...
Collapse
6: Re: ACS approval of interoperability (response to 1)
Posted by Randy Ferrer on 06/05/03 01:42 AM

Found the stuff below. Maybe there is more information in the new release itself. I'll post anything else I find...

"...We also saw a few changes to time oriented data handling, some of which was related to some recent discussions on the -general list. Now when a TIMESTAMP, TIME, or INTERVAL precision is specified larger than our implementation limits, a NOTICE is issued and we use the max supported value. Previously this would have resorted in an error, but the change was needed to allow easy porting from pre-7.3 releases where the limits were higher. We also now allow 60 seconds fields of TIMESTAMP, TIME, or INTERVAL input values. This is actually appropriate for spec compliance and will also help in porting from older pg_dump files."

"Tom Lane added in some code to add code to test for unknown timezone names (following some ideas from Ross Reedstrom a couple months back) and to detect timezones that are using leap-second timekeeping. Along with this he also made DecodePosixTimezone() a tad more robust. Tom also finished removing the support for autocommit from the back end based on recent discussions, though there is still a need to support this on the client side in lippq."

Collapse
7: Re: ACS approval of interoperability (response to 1)
Posted by Randy Ferrer on 06/05/03 01:49 AM
postresql.org is experiencing difficulties with their website. I've been trying to download 7.3.3 all day today and no dice... I'll keep trying...