Forum OpenACS Q&A: Adding Tables to a Portal

Collapse
1: Adding Tables to a Portal
Posted by Brian Mueller on 04/22/00 07:34 AM
When I add a table to a portal, the following error occurs. This
happens whether its one of the pre-defined tables, like the calendar,
or a new, static table.

-----

Database operation "dml" failed
        while executing
    "ns_db dml $db "
            delete from portal_table_page_map
            where table_id not in ([join $good_list ,])
            and page_id in ([join $page_list ..."
        invoked from within
    "if {![empty_string_p $good_list] && ![empty_string_p
$page_list]} {
        # delete tables that didn't appear in our list (hence they
were javascript-del ..."
        (file "/home/acs/acspg/www/portals/admin/manage-portal-2.tcl"
line 147)
        invoked from within
    "source $ad_conn(file)"
        invoked from within
    "if { $extension == ".tcl" } {
            # Tcl file - use source.
            source $ad_conn(file)
        } elseif { $extension == ".adp" } {
            # ADP file - parse and return  ..."
        (procedure "ad_handle_abstract_url" line 65)
        invoked from within
    "ad_handle_abstract_url cns40 {}"

Collapse
2: Response to Adding Tables to a Portal (response to 1)
Posted by Don Baccus on 04/22/00 02:58 PM
Make sure that "logsqlerrors" is set to "true" in your initialization file for the server.  Then post the error from the log file that Postgres is reporting.  Can't really help you without the additional information.
Collapse
3: Response to Adding Tables to a Portal (response to 1)
Posted by Brian Mueller on 04/22/00 03:15 PM
The log file...

[22/Apr/2000:09:09:47 -0400][20631.21063][acspg] Error: Ns_PgExec: result status: 7 message: ERROR:  triggered data change violation on relation "portal_table_page_map"

[22/Apr/2000:09:09:47 -0400][20631.21063][acspg] Error: Tcl script failed for GET /portals/admin/manage-portal-2, User-Agent: Mozilla/4.72 [en] (Win98; I), PeerAddress: 209.206.44.208

[22/Apr/2000:09:09:47 -0400][20631.21063][acspg] Notice: 801 bytes of raw data to follow:
Database operation "dml" failed
...followed by database operation error message above.

Collapse
4: Response to Adding Tables to a Portal (response to 1)
Posted by Ben Adida on 04/22/00 05:25 PM
I've seen this before and I'm not sure what the problem is yet. However, when you have a bug like this, please please post it to the SDM (http://acspg.benadida.com/sdm) so that we can keep track of all of these even if they don't get fixed right away.
Collapse
5: Response to Adding Tables to a Portal (response to 1)
Posted by Don Baccus on 04/22/00 07:31 PM
It appears that manage-portal-2 is updating the same foreign key in portal_table_page_map twice within the transaction held for the duration of the loop that processes your additions/deletions to the portal page.

I believe the restriction is an ANSI SQL92 restriction.  You wouldn't see this in 6.5.3 because referential integrity wasn't implemented until PG 7.0.

To debug this, try turning on SQL logging (set "verbose" to "on") for
the relevant pool, and trace the insert and update statements within the transaction.  It should be possible to avoid the double update.

It's also possible you've uncovered a bug in the new referential integrity checking code.  It would be the first one, amazingly enough.

Collapse
6: Response to Adding Tables to a Portal (response to 1)
Posted by Don Baccus on 04/23/00 04:10 AM
I suggested Brian get rid of the foreign key integrity checks in portal_table_page_map temporarily, as a hackaround, and that led him to another bug, a trigger that didn't return a value.

I fixed and commited that.  The trigger's on a portal table but it's in the education module, grrr...I'm going to report that as a bug as it's a GENERAL trigger that affects all users of the portal tables.  There are several of these.  Classic aD snafu (though the specific trigger error was a PG port snafu).

They belong in the portals module, and I've got to wonder if they don't break the portals module in some way.  Just wondering, since the perp was obviously myoptically focused on the education module at the time and there's no guarantee s/h/it thoroughly tested the portals module afterwards.