Forum OpenACS Development: Re: named objects

11: Re: named objects (response to 1)
Posted by Peter Marklund on
I think named objects should have multilingual names and that this should be supported by acs-core. I appreciate the concern about scalability here but there are various ways to address that issue, an index like Dirk suggests, caching in memory that you already use, maybe both of those approaches.

To me it seems natural to let the table acs_names_objects have the columns (object_id, name, locale) and potentially others that might be needed. Do we want to add description as well?

Concerning package_id that is a denormalization that probably belongs in acs_objects. The proposal by Don, that I agree with, is to drop the context_id (no longer needed by permissions) column from acs_objects and introduce a parent_id column instead. I'm not sure what exactly that upgrade will involve.

12: Re: named objects (response to 11)
Posted by Timo Hentschel on
No, you can't be serious about that. That's exactly a design i want to avoid. Think about it. Adding a locale field will get you into deep trouble because what if you want to get the names of all objects in german, but most of them are not available in german? You should fall back to display whatever language is available (most likely the default language). I don't see a way to do that kind of query in a fast and scalable way or do you?. And caching the names of all objects? I don't think so. The system can be huge and although memory might be cheap, I just think that's too much.
13: Re: named objects (response to 12)
Posted by Dirk Gomez on

How do you intend to support I18N then? Not only for categorization, but also for *every* other package in the system?

In a document called "Best Practices for Globalization using the Oracle 9i Internet Application Server" to which I was pointed at by Mohan, Oracle suggests this:

-- fallback language is English which is abbreviated as 'US'.
CREATE VIEW default_message_view 
  AS SELECT msgid, message 
  FROM messages 
  WHERE langid = 'US'; 

-- create view for services, with fall-back mechanism
CREATE VIEW messages_view AS
SELECT d.msgid,
  CASE WHEN t.message IS NOT NULL 
    THEN t.message 
    ELSE d.message 
  END AS message
FROM default_view d,
  translation t
WHERE t.msgid (+) = d.msgid AND
t.langid (+) = sys_context('USERENV', 'LANG');

SELECT message FROM message_view where msgid = 'hello';

Looks kinda slick: If you don't find a translation with the first index lookup, you need a second one. Shouldn't be that much of a performance impediment: If an average index lookup takes 5 I/O accesses (that's already for a huge table), you add a maximum of 10 I/Os per row.

It *clearly* is much more expensive than returning the name from a row that Oracle has touched anyway (access costs amount to zero there).

The current I18N solution sacrifices performance for tight coupling of related objects. Is it good? I dunno. Is lose coupling - every translated object gets its own row in acs_objects - better. I dunno.

23: Re: named objects (response to 12)
Posted by Thomas Taylor on
Have a look at

This i18n package does not support names for objects or such, but at least some multilanguage design is possible.

24: Re: named objects (response to 23)
Posted by Timo Hentschel on
I didn't say that i18n is not possible at all. Actually, my categorization package is multilingual in that categories can be translated in any language. I'm just saying that doing i18n for object_names so that you can write fast queries without using a cache is a hard thing to do.