Forum OpenACS Development: Change Parameters of an openacs-packege

Hello ,
we have been developing a package for OAcs ,and we have some problems with the apm.
1. How can we change the parameter 'Singleton' , it has to be 't' but was set to 'f' when the developing started.
2. As well we have a problem with packagename-create.sql and packagename-drop.sql files , the Oacs doesn't rcognizes them as install/uninstall files.

And manuly editing  the package.info file doesn't help.

Thanks for your help.

Collapse
Posted by Don Baccus on
What version of OpenACS 4 are you using?  There are currently some issues with the CVS HEAD and the APM.  If you're using one of our standard release tarballs, could you post the output from the APM files info page for your package which shows the file names, their location in the directory structure, and what kind of file the APM thinks they are?

As far as the singleton flag, the UI doesn't support editing it though it should, along with some other basic things it won't let you change.

You can change it by hand-editing apm_package_types in SQL*Plus or PSQL for now ...

Peter Marklund's on vacation until Monday but has been enhancing the APM, perhaps he'll see this note and look into adding UI to edit stuff like this.

Collapse
Posted by Bjoern Kiesbye on
Thanks,
changing the the singelton_p column in apm_package_types to 't', for our package worked.
As well I found out that in apm_package_file_types the different file types are stored, all I had to do was setting the file_type colum in apm_package_files , for our SQL files, to the correct values for data_model_instalation/deinstalation . The package.info file is written with the correct values now.

We use OAcs 4.6, from cvs last updated in 10/2002.

Thanks for your help.

Collapse
Posted by Peter Marklund on
During design of the APM, it was probably thought that singleton_p
does not need to change or should not change between package
versions. As far as I can tell it is the only attribute that is not
versioned (i.e. it is not stored in the apm_package_versions table that
is keyed by version_id). This means that we cannot currently keep track
of old values of singleton_p if that attribute changes. This is probably
not a problem though as I don't think people downgrade packages since AFAIK
this is currently unsupported by OACS (i.e. there are no downgrade scripts).
This makes me wonder if it makes sense to store information about old versions
in the APM at all...

So to conclude things, yes singleton_p should probably be editable. I don't
consider it a high priority feature though (i.e. singleton_p rarely changes)
so I'll probably not get around to implementing it myself.