Forum OpenACS Q&A: Re: Augmenting acs_objects - Add package_id, name, overview, etc. to it

Collapse
17: Re: Augmenting acs_objects - Add package_id, name, overview, etc. to it (response to 1)
Posted by Don Baccus on 01/28/03 10:14 PM
I understand Branimir's comment - acs_object.name() itself executes a potentially expensive query, thus the "50 queries" comment.

So we're balancing code speed vs. space.  And there are folks who already argue that objects are too heavyweight, if anything.  Those arguments will simply increase if we add a name field, much less a possibly HTML-formatted description.

BTW "real" content - stuff that should be in the content repository anyway - already has name and description fields.

Do all objects in the system really require this much information?

Another way to present an abstract view of objects so that generic pages can find a name, etc would be to use standard views to collect the information.  This would still require a join with acs_objects and the type-specific table but would be  less expensive than the name_method approach.

Collapse
21: Re: Augmenting acs_objects - Add package_id, name, overview, etc. to it (response to 17)
Posted by Branimir Dolicki on 01/28/03 11:03 PM
<blockquote> Do all objects in the system really require this much information?
</blockquote>

No, in a system where rel_segment is an object with its own entry
in acs_objects this information doesn't belong to acs_objects.
I don't like the idea of having a bunch of columns that are NULL 90%
of the time.

So, the table in the CR that you mention might be the right place.

I personally wouldn't do it because I think that the whole idea of the Content
Repository is basically flawed (See Lars' posting on the subject about a year
ago or so).

Now, as I am also one of those people (Just as a reminder, I *don't* want to start
that discussion again, 😊 who think that objects like rel_segments are
useless, the optimal solution would be to first remove the useless crap from
acs_objects and then do what Dirk suggested.

Here's what we actually do: We use a separate table called acs_objects_description to
store the information Dirk mentions.  So whenever you decide that your object
type needs to be searchable, bookmarkable and generally behave as a piece of
content, you start adding those rows to acs_objects_description.  You
then join to acs_objects if you need information that is there.