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

Collapse
12: Re: universal way of displaying lists of objects needed (response to 1)
Posted by Don Baccus on 03/10/03 07:57 PM
I also have to add that it seems that we will not only need the name of objects that use the CR, but also for objects for which it doesn't make sense to store them in the CR.
Yes, I agree entirely. My point is that the CR already has a name field and we want to avoid duplication - if people agree to an object name in acs_objects then we should make the CR use that field rather than maintain its own.

If we take the separate table approach then things like the overview field make more sense to me.

In this case wouldn't the logical way to define that separate table be to subtype acs_objects?

acs_object -> named_object ... this would separate out "skinny" non-named, non-overviewed objects from fancy named objects with (possibly) HTML overviews. Then your extra table would just be the type extension table for acs_object and bits of cr_item (name, description) could be folded in, making cr_item skinnier. At the cost of an extra join for cr_items I'm afraid but if enough were to go into the "named_object" field then you wouldn't need that join until you actually pull out a revision ... and they're often BLOB/CLOB so we don't expect great speed out of that operation anyway.

On the other hand pages summarizing objects by name would query against the named_objects type-specific table and not have to chew through internal objects that have no name ...

(BTW probably want to use MIME-type not html_p as does the CR)

Regarding non-revisioned objects ... I've already investigated the implication of setting a revisions revision_id == item_id and at least 95% of the CR code looks as though it would work unchanged. This would give us non-revisionable CR items that would only occupy one object rather than two. acs_object->cr_item->cr_revision rather than (acs_object->cr_item) + (acs_object->cr_revision). I've also toyed with the idea of always making the first revision this way and only creating separate cr_revision objects for versions after the first one ... this is for the future but my point is that I think we can make the CR "skinnier" without killing the advantages of using it.

Also I wasn't implying that 1 or 3 milliseconds was so fast that we could ignore the problem, I was merely providing a datapoint for folks. I'm not terribly interested in worrying about the speed of pages that list thousands of objects, though - we shouldn't have such pages and the fact that we have one such page today in the admin UI is a bug, not a feature IMO. But taking 1/10th of a second to call acs_object.name() for a page with 100 objects displayed is not a particularly short time.

Collapse
13: Re: universal way of displaying lists of objects needed (response to 12)
Posted by Timo Hentschel on 03/10/03 08:36 PM
Don, that subtyping sounds more or less exactly like what i originally intended with my proposal of the extra table!!

I'm personally not afraid at all to maintain the naming information in cr_items and my extra table acs_objects_description, because we could use a trigger to copy the data from cr_items to the other table. Ok, it would mean redundant information but it would speed up queries in the CR, i assume (selects are by far more common than inserts/updates, so i think it's more important to focus on fast select queries). The bottom line to this would be: It's not important at all whether a package stores a copy of the object names in their own tables as long as it makes sure that the acs_objects_description table is always uptodate, although i totally agree with you in saying that the datamodel should be normalized if and where possible, but in the end that shouldn't lead to expensive queries if avoidable.

Attempts to cut down the size of CR tables are always good, i think!

PS: I want to clarify that the mailing list objects mentioned above are just objects each describing a mailing list, i didn't mean actual mailing list postings.

PPS: I thought about mime-types, but i thought that when displaying an object in a list of objects the object overview could only be either text or html, but if other scenarios come to your mind, then i would also opt for a mime_type column.