Forum OpenACS Q&A: Object Types as Objects?

Collapse
Posted by Dean Des Rosiers on

In my work on the general-ratings package I have come upon a situation where it would be very useful to view object types as objects. This is because I'd like to set up a relationship with a rating dimension on one side and an object type on the other. (Actually, it may be a bit more complex, but this'll do for now).

This is how I'll determine which rating dimensions to show for which object. I guess the alternative would be to create a mapping table to map object types to rating dimensions. I'd like to stick to the object model as closely as possible, though.

My idea is to create a new object type called object type proxy. Instances will basically contain the object type name. I'd like to put the question of whether it should contain any more object type information (e.g.: related table names, attribute names) to the community.

Collapse
Posted by Ben Adida on
I discussed this with Don a while ago: there is no reason why
object types shouldn't be objects. After all, in Java, classes are
themselves objects (did I just say that?). However, this is a pretty
large change. Probably something for 4.6, or maybe even later.

Note that doing this also allows for a much more dynamic typing
system (creating object types is like instantiating objects).

Let's put some thoughts down here. It may be possible to
implement this without breaking too much existing code.

Collapse
Posted by Dean Des Rosiers on
I've spent quite a lot of time in Java.  Ordinarily I don't use much "reflection" or "introspection," but when you need it you need it bad.  It's nice to have.

I guess what we would need to do is to hook into the new_object_type functionality and make sure we add a new object type proxy instance for the new object type.  We'd also need an update script.

As I alluded to in the originating message of this thread, I personally am not looking to re-create Java's type system.  I just need to be able to create relationships that have an object-type on one side.  If this needs to wait until some much later release, that's fine.  I guess I just don't want to push back general-ratings too much.  Associating rating dimensions with object types is a pretty important feature to me, though.  Any thoughts?

Collapse
Posted by Titi Ala'ilima on
What do we get by making them objects?
  • permissions
  • relations
  • use of general-* (we could rate our favorite object_types! 😊
  • integer primary key

It's not clear to me that any of these are huge wins, but if we can get them real cheap, I guess it can't hurt. I don't see any big pitfalls to doing it. It'll take a little consideration to do it right, but the amount of work is pretty small.

  • change acs_object_types table (new key, unique constraint on object_type)
  • add new and delete functions to acs_object_type package
  • make sure all foreign keys referencing acs_object_types use the right column (easier than making them all use the integer key)
  • arrange the appropriate order for data model installation (table acs_object_types, table acs_objects, package acs_object, package acs_object_type)
  • write upgrade scripts that drop constraints, alter tables, insert objects for existing object types, and add new constraints to replace the old ones (tricky, but not impossible)

However, to answer Dean's original question, I'd still go with a mapping table. It's hard to imagine using acs_rels would be of any great benefit.

Collapse
Posted by Stephen . on
Support already exists for assigning object ids to arbitrary rows. See: general_objects at the end of acs-objects-create.sql.
Collapse
Posted by Stephen . on
One of the other things you could get by identifying object types by object id is support for run time creation.  End users don't give a hoot about system wide unique text primary keys, so you will have to come up with some scheme to generate them (reinvent sequences), or teach end users about the rules of creating primary keys.  If integer object_id primary keys are used to identify object types, the  text identifier object_type can be dropped (saving 30 bytes per row in acs_object_types, all the tables which refer to object types, and their indexes)

Of course there is still a need for programmers to identify some object types by name.  We already have a scheme for this, acs_magic_objects, a mechanism for assigining unique text labels to object ids.

The upgrade script would be... a challenge.

Collapse
Posted by Don Baccus on
general_objects is very useful for mapping ACS 3'ish stuff to objects if you ever have the need (I haven't but it would be useful!)

A simple "object proxy" as Dean talks about wouldn't have to be generalized and would be simple.  Dean and I have talked a bit about this, and as Ben states he and I have talked about the general issue.

Ben ... one reason we've discussed this "proxy object" style of solving the problem is backwards compatibility.  We don't want to break existing sites nor do we want to provide a difficult upgrade facility.  If someone comes up with a simple way to alter the datamodel on an existing site to something that makes object types 100% objects I'd be more than willing to drop Dean's suggestion, which is an admitted kludge.

But it's the same kludge I've been kicking around ...

More elegant kludges are welcome, too ... though as kludges go this one's not bad!

But a ground-up redesign of how object types are declared and used in the system may be impossible at the moment, particularly considering that PG's "alter" capabilities are somewhat weak.

I'd love to be proven wrong, of course!