Summary
ACS 4.2 is no longer maintained by either ArsDigita/RedHat or the OpenACS community. The latest version of OpenACS is 4.6 (due mid September 2002) and incorporates many bug fixes and enhancements to the original ACS.
In order to take advantage of all the new developments (including dotLRN), an upgrade is necessary. As this is a live system, careful planning needs to take place.
Technical Hurdles
While OpenACS is very similar to the original ACS architecture, some significant changes have been made to some database schemas.
The other hurdle will be moving from Oracle to Postgres. It really makes sense to do the complete port now instead of trying to simply upgrade and leave Oracle as the backend. While this may be simpler in the short term, it is actually more work in the long run if the plan is to go with Postgres as the final database.
One advantage of OpenACS is database neutrality, this means that code can run in either Oracle or Postgres at this time. The new package manager allows for running legacy code so the system can be changed over and using the advanced features of the Package Manager can be left for the long term.
Benefits
There are many benefits to upgrading to OpenACS 4.6. The following is a short list:
- Much more stable with many code fixes in the kernel.
- Improved templating system with bug fixes.
- Improved forms system with bug fixes.
- Much enhanced Permissions model.
- User interface is improved.
- Groups administration is simplified and has many fixes.
- Portals are implemented cleanly and are user friendly.
Options
Upgrade existing installation as needed.
One option (albeit not a good one) is to simply try to patch together the changes from OpenACS into the existing system. The advantage is that the data doesn’t need to be exported and then imported into the new system. In reality, this is a solution fraught with danger, both in terms of time and effectiveness.
Upgrade to OpenACS but leave Oracle as the backend.
Upgrade to OpenACS and convert to Postgres
Plan
No matter which direction is chosen some common things need to happen.
- Scripts – Scripts need to be written to export the data, possibly massage the data and then import the data. This comes about due to the need to keep all the content related to the correct users.
For example bboard posts are posted by a user. This user has a unique user_id, in order to do the correct import, either that user_id needs to be mapped to a new user_id or a system created to reuse the user_id’s.This needs more research and will be the most technically challenging part of the conversion.
- Validation – This is more of a QA domain, but still must be planned for. A person or group of persons that has an intimate knowledge of the system needs to check that the scripts above properly converted the data.
- Freeze – There needs to be a firm date when the live system is frozen. It can be left running, but must be read only to prevent data from getting out of sync when the conversion happens. Fortunately, if you aren’t a 24/7 ecommerce company this can happen on a weekend when the site is not being heavily used.
- Cut-over – This coincides with the Freeze above. After the system is shut down or placed in read-only mode, the cut-over will begin.
- Backup plan – A contingency plan needs to be in place in case problems are found in the cutover. Generally if the problems are noticed in a day or so, we can simply put the old system back in place. However, there may be a delay in problem reporting. In this case some system for either updating the old system with any new data or, depending on the severity, fixing the live system, needs to be in place.
Glossary
ACS
dotLRN
OpenACS
ARSDigita
Postgresql
Oracle
Tcl
This work is licensed under a Creative Commons Attribution-ShareAlike 2.5 License.
