Forum OpenACS Improvement Proposals (TIPs): TIP #43 (Approved) Adding object_name to acs_objects

Request notifications

Proposal

Add object_name to acs_objects table. See here

Reason

Most of the objects are in some way displayable and named (except for some internal objects such as acs_rels). Services such as categories or search need to be able to display (potential) long lists of objects with their names and let the user sort by the name. Doing this by using the current acs_object.name interface in pl/sql is inefficient and unscalable for longer object-lists and does not solve the problem to order by that name.

Disadvantages

Some objects don't have a name and therefor will need to store null values. We will need to duplicate inserts and updates on the pretty names of the package-specific tables. We will only store the names in one locale, so multilinguality is not supported.

Solution

Add triggers or change pl/sql functions for every package with named objects. Add and change core functions. Add column "object_name" of type varchar2(200) (or something the like) to table acs_objects without a "not null" restriction.

Will do the changes of the core and the packages news, forums, blogger, file-storage, categories, mailing-list and someone else should change the other packages.

Collapse
Posted by Dave Bauer on
First,

Lets make it clear what we are talking about. The attribute you need is the display name, or pretty_name as it is commonly called in most OpenACS tables. For the content repository its the cr_revision.title.

Collapse
Posted by Jeff Davis on
I vote yes (although I like calling it pretty_name
better and I don't like making it not null since I think
for some things there is just not a meaningful pretty_name).
Collapse
Posted by Dirk Gomez on
We have mapped out ways to support multilinguality. And do we really want to pull in non-localizable code after having i18nized the whole toolkit?

Where is package_id? Will that be a different TIP?

What about upgrade scripts or ways for a smooth migration? Do you have a tippable proposal for this?

Collapse
Posted by Lars Pind on
I side with Jeff and Dirk on this:

1. pretty_name is better. UPDATE: title may actually be better, for consistency with CR, which we want to move to for these kinds of objects, anyway.

2. we need to handle i18n.

/Lars

I'm in no way insisting on naming it object_name - pretty_name or title would be equally ok for me.

The thing with i18n is that nobody could come up with a reasonable solution to cope with objects in multiple languages (this shouldn't happen too often anyway). Since the feature of having a pretty_name or title of an object at a central place would help solve some immediate problems (i.e. search and categories) i would still want to see this being implemented. If a reasonable i18n solution comes up later we can still update then.

Collapse
Posted by Dave Bauer on
Is one solution for i18n a seperate table with one row for eac h object_id/locale? Should we consider this or defer to a later time and just implement as an attribute of acs_objects for now?
Collapse
Posted by Lars Pind on
I think we should decouple this TIP from the i18n issue, because it is more involved than what this TIP is about. We need some discussion, then a separate TIP for the i18n issue.

I've started the discussion here:

http://openacs.org/forums/message-view?message_id=161009

/Lars

Can I assume this TIP got approved if I'll use title and disregard i18n for now? (please let's move the i18n issue to a seperate TIP)
No, the TIP didn't actually get any Approved votes, or any Yes votes, only one "Yes with caveat" vote.  Please summarize the changes, if any, and re-TIP.  I know it seems like bureaucracy, but one purpose of TIPs is to leave a clear record of what we decided, and that means that the proposal text must be complete - if you have to read the TIP and ten comments and figure out which comments were definitive changes and which were opinions that may or may not have been accepted, then TIPs offer little advantage to forum discussion.
Can I assume this TIP got approved if I'll use title and disregard i18n for now? (please let's move the i18n issue to a seperate TIP)

Approved

Collapse
12: Re: TIP #43: Approved (response to 11)
Posted by Lars Pind on
/Lars
Approved
Collapse
Posted by Dave Bauer on
Approved.
Approved
Collapse
Posted by Don Baccus on
I approve, too.  I would like this and the package_id TIP to both include notices that package-specific table package_ids and pretty_names - including the CR's title - will disappear eventually to encourage package authors and maintainers to start migrating to the use of the base object title (which I prefer over pretty_name) and package_id.

I realize we won't be able to ALTER TABLE CONTENT_ITEM DROP TITLE until, say, late fall or winter but I would like to see us put folks on notice that this is the direction we're moving in and that they should consider migrating sooner rather than later.

Collapse
Posted by Roberto Mello on
Approved. I agree with Don's remarks on this TIP.

-Roberto

Don, can you clarify your comments please? (Maybe in the developer forum) - what you are saying sounds scary, but I'm sure it's not!

PS: Are non-oct members allowed to make comments here?

Collapse
Posted by Don Baccus on
OK, to clarify ... if we're going to ratinonalize the object structure, for instance adding the "title" field to objects, at some point we'll want to remove the redundant title field from CR objects and rely on the title field of the base acs_object type.

We can't do this right away and need to think about upgrade scripts.  Code that uses the special views created for content_types can perhaps remain unchanged because our upgrade scripts can rewrite the views to use the proper title field.

Timo ... better make sure the new title field is at least as large as the one in CR objects.

But Mark, don't worry, we won't take any steps that can't be solved in an upgrade process.  I just want folks to understand that our goal is to simplify and unify the object/content item issue, not to further divorce the two by maintaining redundant fields!

marked approved