Forum OpenACS Improvement Proposals (TIPs): TIP #43 (Approved) Adding object_name to acs_objects
ProposalAdd object_name to acs_objects table. See here
ReasonMost 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.
DisadvantagesSome 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.
SolutionAdd 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.
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.
better and I don't like making it not null since I think
for some things there is just not a meaningful pretty_name).
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?
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.
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.
I've started the discussion here:
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.
PS: Are non-oct members allowed to make comments here?
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!