Forum OpenACS Q&A: Tcl Callbacks

Posted by Christian Paolo Vásquez Chávez on
I was trying to uninstall the news package, but when I run the drop script I got this error:

Database operation "0or1row" failed (exception NSDB, "Query was not a statement
returning rows.")

ERROR:  update or delete on "acs_objects" violates foreign key constraint
"acs_objects_context_id_fk" on "acs_objects" DETAIL:  Key (object_id)=(559) is
still referenced from table "acs_objects".

select apm_package__delete('559');

It was because there were news items in the DB, so I drop them using this funtion:

create function inline_b0 ()
returns integer as '
            v_item_cursor2 RECORD;
RAISE NOTICE ''Entro a la funcion inline_b0()'';
    FOR v_item_cursor2 IN
        select item_id
        from news_item_revisions
        PERFORM news__delete(v_item_cursor2.item_id);
' language 'plpgsql';

When I run this from PSQL it deletes all the items.
So I run the drop script and it worked very well, so I decided to make an Tcl
Callback, I call the function this way in the before-uninstall callback:

db_exec_plsql news_f {
  select inline_b0();

Then I run the "Uninstall this package from your system" option in the APM, and postgresql stopped in the funtion content_type__drop_type()

-- drop CR content_type
select content_type__drop_type(
        'news',    -- content_type
        't',      -- drop_children_p
        't'        -- drop_table_p

I don't know really why is this going on.



2: Re: Tcl Callbacks (response to 1)
Posted by Joel Aufrecht on
This is unfortunately rather normal.  Many packages fail to uninstall because removing all of the acs_object and cr_item records is fairly difficult.
3: Re: Tcl Callbacks (response to 1)
Posted by Stan Kaufman on
This is unfortunately rather normal. Many packages fail to uninstall because removing all of the acs_object and cr_item records is fairly difficult.

This being the case, what does this tell us? I've been trying to work out why even some of the most mature current-generation packages like Bug-Tracker don't uninstall cleanly as a means to figuring out how they work. Wonkiness seems to erupt when the deletion routines descend into the acs object system and the CR. Are the uninstall procs incorrect? Are there actually undiscovered problems with the way acs_objects and CR entities get created that the (correct) uninstall procs uncover? Are the core mechanisms OK and the problem is entirely in the package-specific drop scripts?

Presumably the answer may vary from package to package. For instance, Bug-Tracker stalls in the middle of its drop script (../bug-tracker-drop.sql). There were some obvious simple errors (a couple drop function calls with incorrect parameter lists). Even when those are fixed and the drop script runs fine via psql, it still barfs when being run within OpenACS. No clue why at this point. (This is a HEAD install btw.)

However, it seems vital to me that packages uninstall cleanly. A botched uninstall leaves the entire database's integrity in question. In a development setting, simply dropping the db and starting over is acceptable, if tedious. But that's not an option in a production site, obviously.

As packages get designed with more and more inter-package dependencies, it becomes essential that reliable uninstall procedures be present so that during development and testing, we don't have to completely start over with a new install each time. If my new package doesn't remove cleanly, I'm not confident I've built it cleanly. And I want to be certain that any uninstall problems are due to my drop scripts, not the complex series of calls that begin with apm_package_delete (in packages/acs-tcl/tcl/apm-install-procs.tcl)

4: Re: Tcl Callbacks (response to 3)
Posted by Jade Rubick on
I really agree with Stan -- clean drop scripts are very important, and not having clean drop scripts hinders adoption of OpenACS.

My largest concern is that many developers seem to think drop scripts are not important.

Perhaps the easiest way to ensure that they happen is to add something to the documentation on how to write good drop scripts. A well-commented drop script, showing what every drop script should contain, would be a welcome addition to the documentation.

Any idea on what would be a good candidate?

5: Re: Tcl Callbacks (response to 1)
Posted by Stan Kaufman on
Jade, I started with Bug-Tracker and Project-Manager because I thought that they were the most likely to work correctly; neither does at this point. ;-)

I am also worried about the complex procs involved in uninstalling -- not just the drop scripts. For instance, if a package does successfully uninstall (ie no obvious errors), it should show back up in the list of available packages to be installed. But it doesn't necessarily. (I need to reexamine this and post some better details; this is something I noticed a while ago.) I wonder if the caches aren't getting correctly updated. The proc calling cascade is certainly opaque and hard to troubleshoot.

6: Re: Tcl Callbacks (response to 5)
Posted by Jade Rubick on
Stan, please do post any bugs you find in the drop script for project-manager. I tested the drop scripts quite a bit while developing project-manager, and until recently, they worked for me. So I'd like to know of any issues you're having.

Please do post bugs on the APM too, if that's not working.

Basically: please be a squeaky wheel. This needs to change, and I'll put my action where my mouth is!

7: Re: Tcl Callbacks (response to 1)
Posted by Nima Mazloumi on
Why not make it a rule for future releases?

Any package that has no proper unistall should not be part of the release and part of the repository.

What do you think? This sounds hard in the first place but will create more awareness for the importance of this issue.

8: Re: Tcl Callbacks (response to 7)
Posted by Jeff Davis on
A good start would be a list of which packages don't uninstall. Maybe the people who care can go through and ticket which ones don't uninstall on postgres and oracle.

Keep in mind it's important to add data (and notifications and categories and comments etc) before uninstalling since a lot of problems only show up once that extra data is added.

9: Re: Tcl Callbacks (response to 1)
Posted by Stan Kaufman on
Jeff, I'm happy to take this on since I'm one who was whingeing on about it so. What I intend to do is start with a fresh core install, and then sequentially add single packages (along with their dependencies obviously), create a bit of data, and try to uninstall the target package individually (ie not uninstalling any of the dependent packages). I'll file bugs on each package that won't uninstall along with whatever clues I can get re cause from the error log.

I have a several questions:

  • Since some of the uninstall problems may be with the apm, which version of core should I use -- HEAD? 5-1?

  • Which version of the target packages should I use? HEAD? 5-1-compat? (Despite Tip 61, I still am confused about where bug fixes are supposed to go, where they actually are going, and why. Bug-Tracker patches have been committed to HEAD but not 5-1-compat; Project-Manager patches have been committed to 5-1-compat. What is supposed to happen?)

  • Since the uninstall proc chain (beginning with apm_package_delete) includes stuff to remove site_nodes, I presume that to uninstall a package, the idea is simply to go to the Package Manager page and uninstall it without first unmounting and deleting the package instances from the Site Map. Is this correct? Or is uninstalling supposed to be a two-stage process where the user first removes the mounted packages via Site Map and then goes to the Package Manager? (If so, this should be documented somewhere -- like on the PM page "Warning -- remove all instances of the package from the Site Map first!!")
10: Re: Tcl Callbacks (response to 9)
Posted by Jeff Davis on
Just take a checkout via:
cvs co -r oacs-5-1 openacs-4
and submit bugs as found in "5.1".

I think you are a little confused on terminology: you can't commit on "5-1-compat" it's not a branch, the branches we currently are working with are oacs-5-1 and HEAD. openacs-5-1-compat is a "symbolic tag" and serves as an alias for the latest versions of a package which have been marked as compatible with the 5.1 release. You can only commit to a branch -- someone then needs to update the opeancs-5-1-compat symbolic tag to point at the latest version of that file on the branch on which the 5.1 compatible version of that file lives (for everything except project manager that symbolic tag should be pointed at the latest tested version on the oacs-5-1 branch).

In terms of testing uninstall, yes, I think the uninstall should work even if it's mounted so don't unmount things first -- just do the delete via the "Uninstall this package" at the bottom of the version view linked from the /acs-admin/apm/ page.

11: Re: Tcl Callbacks (response to 1)
Posted by Stan Kaufman on
Jeff, thanks for the clarifications.

I think you are a little confused on terminology

Yes, this happens whenever CVS comes up. ;-)

12: Re: Tcl Callbacks (response to 1)
Posted by Ian deng on
I have the same issues as well, but the main concern was not the drop script. If I leave items in the database and try to uninstall the package, it returns an error.

The reason I think this is happening is because the APM runs apm_package_delete function before it runs the drop script. That means the error occured before the drop script is executed, that means it not the fault of the drop script. But if the drop script was executed before the apm_package_delete function then problem would be solve.

Does anyone has any suggestions to the problem?