Forum OpenACS Development: Response to Gratuitous use of acs_objects?

I was discussing this with Branimir Dolicki the other day, and he told me about what they'd done on one of their projects. He'd ripped out the "parties" and "person" tables so that your user info isn't spread out across four tables, but only two: acs_objects and users. This by itself reduces the number of acs_objects considerably and speeds things up. It took them about 4 developer days to do it across the board, and they're really happy they did it.

How does reduce the number of objects? It will reduce the number of joins and tables, but a user in the hierarchy object->party->person->user occupies only one object. As far as the utility of "persons" ... I too have had the need for non-registered users to be included in the system.

Now ... one thing I think we really need to do is to get rid of the need for a new object subtype to declare and use a new table, and also the restriction that only one type is allowed to point to any given table. The latter restriction prevents you from, say, defining two types ("person" and "user") that share a table, which in the "person" case could be left partially empty. One could still enforce the requirement that the information be there for "user" objects, while providing the flexibility of being able to add "persons" that aren't "users" and having the full advantage of the type system.

And that gets rid of one of your tables. I think that "parties" are probably an unneeded intermediate level, so that would get us down to two tables. Just like Branimir's solution but without throwing away as much functionality.

BTW the above thinking is representative of my thoughts about the object system. It needs some cleaning up, and some judicious changes would allow for more flexible subtyping leading to subtyping being a lighter-weight thing.

Next step will be to de-acs-objectize acs_rels and membership_rels.

I think there's value in being able to build the complex relationships implied by their being objects. However ... the individual rows in the relationships are also, I believe, objects. And they don't need to be/shouldn't be? I'm blowin' smoke, here, I haven't looked closely at the issue. But if I'm right then the proliferation of objects due to mapping rows could go away, without losing the flexibility of having the rel itself an object.

I agree with Branimir that only users, groups, package instances, and content should be acs_objects. Content being things like a bboard posting, a file in the file storage.

Not sure I'd go this far. In fact, several folks have come up with examples showing that having object types be objects would be useful. It may be that we're not using the object system enough, rather than too much.

We need to concentrate on making the object level as lightweight as possible ... regardless of what we choose to make objects.

And while we're at it, I also agree with him that the content repository is created upside down. What we really need from the content repository is a central place to store title, description, and other generic info that you need for site-wide search or a "what's new" page. Instead of the kludgy acs_object.name() function, which has to do dynamic SQL to figure out something as banal as the name of an object.

I think it's too heavyweight, too. I haven't thought too much about a solution, other than the fact that it's currently rather monolithic and as you point out, lacks a simple foundation.

Thoughts on this? Might as well start the discussion about what to clean up for our next big release :)