Forum OpenACS Q&A: Re: universal way of displaying lists of objects needed

7: Re: universal way of displaying lists of objects needed (response to 1)

Posted by Don Baccus on 03/10/03 05:48 PM

In my opinion query speed is the topmost design-criteria overruling every other criteria possible

I'm old-school - correctness should be the design criteria overruling every other criteria. Hopefully folks designing airplane control software, etc, still follow this old-fashioned way of thinking.

I've measured acs_object.name() and on my P500 it runs about 3 milliseconds in both Oracle and Postgres, not terribly slow but not terribly fast, either. On a modern system I'd expect performance to be closer to a millisecond.

Denormalizing by carrying the name in acs_objects isn't that big a deal, but ... it does involve munging code to make sure it's maintained correctly. At minimum anyone doing this who expects to find their work accepted into our mainstream OpenACS core is going to have to address the fact that content items already contain a name field, and provide upgrade scripts to migrate that to acs_object as well as fix all our standard packages that use the CR. That would not be a lot of work but it is necessary work.

The name column was the one proposed extension to acs_objects that I felt had some merit, others just seemed to widen objects in ways better handled by keeping content in the already-wide content repository. Denormalizing content URLs for instance makes sense but I'd rather see that stored in content item (in part to heavily encourage folks to put their content there instead of ignoring the CR's existence)

9: Re: universal way of displaying lists of objects needed (response to 7)

Posted by Timo Hentschel on 03/10/03 06:14 PM

Ok, ok, correctness is a little bit more important than speed, i guess...

Regarding the speed of acs_object.name(): It is nice that it runs fast on your machine, but i don't know many million objects your system is holding and how many concurrent page requests your system does have.... Under load a system has to serve every page as fast as possible and i think i made it pretty clear that the invocation of pl/sql procs for every object to be displayed in a possible long object list (yes, normally a long list should be split on several pages, but still...) just has to be way slower than my proposed approach. That doesn't mean that acs_object.name() should not even be used to get the names of a limited number of objects. I'm just saying that this proc is one of the ad inventions that seemed nice on first sight, but if you really think about it and really try to use it in a huge system then you realize how flawed that approach is.

Regarding migration: Yes, i will make sure that migration scripts for the major packages will be written (anyone here for help?).

If you already agree that adding a name column to acs_objects (or a second table as i suggested to not blow up acs_objects unnecessarily since we don't need these infos for every single acs_object) makes some sense, then why not also adding at least package_id if not state, overview and overview_html_p?