• last updated 8 hours ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Fix bug in etp-swap (thanks Jun)

fix two new bugs in get_content_items

Fixed file update error in postgreql. It adds an mtime column, update your

datamodel on PG. Code checks for storage_type to run the correct queries/code

for Oracle/PG.

update for Applet_Add

consistency update

use bind variablescvs update ALWAYS

fixed up a few things

    • -1
    • +24
    /openacs-4/packages/dotlrn/tcl/dotlrn-init.tcl
    • -0
    • +12
    /openacs-4/packages/dotlrn/tcl/dotlrn-procs.tcl
    • -10
    • +4
    /openacs-4/packages/dotlrn/tcl/dotlrn-procs.xql
    • -0
    • +3
    /openacs-4/packages/dotlrn/www/one-community.tcl

Removed some misnamed files from file-storage and removed a garbage file

from static-pages.

improved views

fixed the calls to the new dotlrn applet contract

    • -1
    • +1
    /openacs-4/packages/dotlrn/tcl/dotlrn-procs.tcl
updated the whole architecture to do dotlrn_user_rel, and portal-id

    • -6
    • +14
    /openacs-4/packages/dotlrn/tcl/dotlrn-procs.tcl
    • -2
    • +8
    /openacs-4/packages/dotlrn/tcl/dotlrn-procs.xql
  1. … 27 more files in changeset.

Changed to the new tree_sortkey comparison scheme. Mostly untested (yet)

will do so shortly!

1. Replaced more "tree_sortkey like" with "tree_sortkey between" expressions

2. Fixed a bad port of an Oracle query in site-nodes-procs.tcl and removed

a needless outer join from both versions in the process.

After importing openacs.org users, forums and messages I discovered that it

took literally several minutes to load the APM's home page. This was due

to a rather stupid subselect of the form:

select count(*)

from content_revisions r

where r.revision_id = content_item.get_latest_revision(item_id)

where item_id comes from the package versions table.

It's stupid in both PG and Oracle because get_latest_revision already

joins the latest_revision_id value from cr_items with the content

revisions table thus a simple check for a null return by get_latest_revision

would be sufficient.

It's *really* stupid in Oracle because Oracle won't use the index on

revision_id when checking NULLs so we get two sequential scans of the

cr_revisions table tucked into that one itty-bitty subquery (itself called

once for each package version in ths system).

Which explains why I hadn't noticed it while working on scalability testing

in PG - PG uses the index because its btree index structure handles NULLs.

Meaning this query only fell apart at a rate of O(log2(R)) rather than O(R)

as in Oracle (R being the number of revision objects in the system).

My solution was to rewrite the subselect using "case" rather than "count(*)"

and also to speed up get_latest_revision by having it check for NULL and

return NULL immediately rather than execute the query (in PG this is

accomplished by declaring the function "isstrict", and the executor won't

even call the function if the argument's NULL, making it REALLY fast!).

ToCommunity update

ToCommunity updates

_to_community updates

ToCommunity update

to_community updates

add to_community stuff

Saving changes.

    • -0
    • +12
    /openacs-4/packages/rss-support/www/subscr-run.tcl
fixed an oracle XQL bug

moved things to package_instantiate_object

    • -76
    • +31
    /openacs-4/packages/dotlrn/tcl/class-procs.tcl
    • -15
    • +102
    /openacs-4/packages/dotlrn/tcl/community-procs.tcl
    • -0
    • +20
    /openacs-4/packages/dotlrn/tcl/dotlrn-procs.tcl

Check the comments in postgresql.sql - my previous commit didn't quite work

as expected.

I also removed an ugly assumption made in the PG port in bboard-procs.tcl.

updates

add applet/user update

add user/applet updates

add applet/user updates

Changed operations "AddApplet" and "AddUser" to refer to one time init

operations. The new ops "AddAppletToCommunity" and

"AddUserToCommunity" will replace the old ops.

Added "tree_left" and "tree_right" in order to optimize tree queries, which

I did for the bboard package. "LIKE (tree_sortkey || %)" never uses the

index as we thought it did, as it turns out ... see postgresql.sql for

example queries that do.