Lars and I have talked about the fact that both revisions and items shouldn't need to be objects. On the surface this seems very attractive, but ...
- A cr_item should be an object so we can assign permissions to it. ACS 3 had a funky relational table containing pairs as the permission key. This was awkward to work with and having a single object space that permissions works on is a real advantage, IMO
- acs_objects contains the basic audit information you want to keep about an item (creation date, creation user, etc). If revisions aren't an object you lose that. It could be replicated in the revision itself but we don't want to start duplicating such stuff again ala ACS 3. After all duplication of effort to continuously replicate basic stuff like this in ACS 3 was one of the motivations for creating a common table to hold it all in ACS 4.
And inheritance is a very useful thing to have. In regard to the content repository, I think a better Tcl API would make it easier to use (I always write Tcl API procs for my custom content revision types) and judicious caching will erase any performance concerns.
PL/SQL ... nearly all of the selects in the system are done from Tcl, so we're not getting much benefit from the wrappers that are there now. insert/update operations are always comparatively slow so caching plans for them isn't a big win plus the plan for a basic "insert" is so simple that Oracle won't take much time generating it. As Stephen points out most of the various PL/SQL functions just wrap simple DML statements - they don't really provide a significant abstraction layer, they just make porting harder.
