Jun, hang on. So all the data is in the database, just retrieving it is so
incredibly expensive that you hack together something on the TCL layer to make
it work somewhat properly?
While this is - err may - be viable for a project under deadline pressure, a
toolkit shouldn't be based on such kludges. You want to change a broken data
model here.
I'm a bit astonished that the acs_object model seems to be taken for "cast in
stone".
As Guy Harrison, a *real* Oracle expert, reasons on page 489 in his *most
excellent* book "Oracle SQL High-Performance Tuning" - the OpenACS' object
model performs *worst* of the three possible sub-type/super-type design
models. It's the worst choice in every possible case except for full-table
scans of the supertype table.
(Now, that case doesn't make sense in OpenACS because fields in acs_objects
don't make sense without a join with one or more sub-tables or calling
expensive PL/SQL function - hence weare falling back to the poorest choice
again - expensive scans).
Adding semantically useful fields to acs_objects makes the "object" data model
considerably more useful! In my book almost every (every?) acs_object has a
name and a context. Heck, most objects even have a verbose description.
Now back then - Mid 2001 - , it didn't look like a wise decision to use the
content repository. I was told that these days the CR is in a much better
shape, so if the name and the package_id is there, then let's use it
asap. Don, can you try a little scaling test there?
