That would definitely be needed. I think it was lacking since ACS 3.x
What we used to do in ACS 3.x is that. For each incremental SQL
change that we did we kept a SQL file to run. After about a period we
then compiled these SQL files into one install SQL file. We then run
this SQL file after the bare installation. It was not that effective.
As sometimes the complex changes in the database such as ecommerce
module was done in the admin interface.
I wonder what is the best way to solve this.
Maybe if we have the packages record the SQL calls. Here is how it
goes. You have to install a bare OpenACS then maybe on the config
file of aolserver there is a flag say called acs_record_steps.
You then do you interactive stuff on the admin, create folders in the
files storages ,etc. When DB calls are made and if the package
supports it then writes a log of calls to the database. Of course
each package has to be acs_record_steps aware. For example file
storage records the folder name you create but does not keep the
folder id.
After you are done turn of the OpenACS and run this log to a bare
OpenACS site. So basically it runs everything that you have done
interactively.
This approach may have its benefits:
- flexible enough for each unique needs of a user and each unique
behaviour of a package. After all its the package author who should
be aware what stuff is needed to create and what do discard.
- can be applied on a module basis. you can just record on a single
module then run it on another site as if you administered it
interactively.
Disadvantages:
- prone to human error. Your error is recorded too and replicated
to all the sites that you run the record log.
- Each package must be aware and implement it.
- Time consuming on the first time especially if the site has lots of
state to save. You have to go to each step the first time.
OR
Possibly create an uber script that saves the states of all known
packages. No work for the packages authors but a great technical feat
on who can do this uber script/dumper.
OR
Have each package give a set of scripts to store state. Although the
first one is more flexible. It might be possible that the author has
not thought of all cases how his/her package should be saved.
Any other ideas on how to save the ACS state?
I think this is very useful. Especially for sites that relies on CMS.
In the old days just copy the html files from staging to live. How
about in CMS? Upload the file, go through the workflow, publish it ,etc.
