Forum OpenACS Development: Re: Augmenting acs_objects - adding package_id, name, and clarifying other fields

Collapse
11: Re: Augmenting acs_objects - adding package_id, name, and clarifying other fields (response to 1)
Posted by Tom Jackson on 11/04/03 08:36 PM

What problem does it solve to add package_id and subsite_id to acs_objects, that you couldn't get from a mapping table? When you add fields to acs_objects, does that require you to modify pl and tcl apis for all objects? I guess I keep missing the point of what problem requires the extra fields to be in acs_objects? Shouldn't acs_objects only contain fields used or useable by every object?

Collapse
13: Re: Augmenting acs_objects - adding package_id, name, and clarifying other fields (response to 11)
Posted by Malte Sussdorff on 11/05/03 07:32 AM
I guess we are coming down to the question of performance vs. clean design here. I do agree that mapping tables would be the way to go in an ideal world. But they always have the drawback of one additional join. If we make more of them, then we have more joins (e.g. one for package_id and one for subsite_id).

So I think adding certain items to acs_objects and removing them as Jun suggested from CR would make sense. Especially as we so far have not made a decision on whether to strongly encourage usage of CR in every module. It would be bad to add functionality that can be used in categorization and search to CR and not having all modules use the CR.

Collapse
14: Re: Augmenting acs_objects - adding package_id, name, and clarifying other fields (response to 13)
Posted by Dirk Gomez on 11/05/03 09:52 AM
Why clean design vs. performance? I am seriously asking whether there is a *must* to have a mapping table or not. I am not yet convinced that there is, so it is clean design to add package_id to acs_objects imho.

The fields to be added are useful for every object.

Collapse
20: Re: Augmenting acs_objects - adding package_id, name, and clarifying other fields (response to 13)
Posted by Tom Jackson on 11/05/03 05:35 PM

Performance vs. clean design? I thought it came down to what the requirements were, first off and if the fields added really belong to every acs_object.

If it is conceivable that someone would want an object to have zero or more packages or subsites it should be related to, you are stuck with a mapping table. Performance cannot be deteremined until someone lists what they are trying to do, why that is curretly hard to do, and what the new solution would do to make the situation better. You also need to include negative effects.

If you move package_id out of object specific tables, then display inside the application requires an extra join. But it makes it easier for someone to find all objects related to a package. Which is more likely to impact performance? What if you need a one to many relationship?

Many basic objects don't need this, and package_id and subsite_id could never contain a valid value. users, parties, group, rel_segments, acs_rels, etc. Acs_objects needs to contain fields common to _all_ objects, or at the very least only fields which could have valid values for all objects.

Finally maybe some extra fields could be removed from acs_objects: context_id. It hasn't been considered yet, but it might be useful to have more than one context for an object. Also, a lot of applications don't even use this field, so it has a zero or more relationship to other objects. (If you used a tag of 'context', maybe you could use the same object_map table.)