Forum OpenACS Development: Joining to acs_objects and package-aware packages

"Try not to write queries in your application that join against acs_objects."

Remove this sentence as it is misleading. I think the key sentences in the document that conveys what they are getting at is:

"Second, in order for this to work, the various parts of the OpenACS Objects data model must be interpreted in the same way by all applications that use the data model. Therefore, assigning any application-specific semantics to any part of the core data model is a bad thing to do, because then the semantics of the data model are no longer independent of the application."

I think what spurred this warning was that applications were using context_id to indicate object context (or navigation) hierarchy rather than merely permission inheritance.

My vote is to take out the last bullet point altogether. The issue with the context_id is not important enough to warrant being in the summary. Or, if it is to be in the summary, make the bullet say something like:

"Don't rely on the context_id column in the acs_objects table to signify the hierarchy of objects. The column is merely intended for inheritance of permissions"

I happen to be one of those people who think that the context_id column should in fact indicate *both* the permission inheritance *and* the object hierarchy. Sometimes when package developers misuse the core it's an indication that the core should change. I'm not sure exactly what needs to change though to enforce such new semantics of the column. Anyhow, until we have made that change, the documentation should reflect the old state of affairs.

Regarding this forum my understanding is that it is for the development *of* OpenACS. I think that includes package development and not only core development.

Now ... I've been doing some thinking about the context_id and object hierarchy issue over the last couple months, in particular when I did the permissions denormalization work for 4.6.1.

We don't really need context_id at all in objects, nor do we need security_inherit_p, because these values are denormalized in the context_object_hierarchy map which is managed by triggers on the objects table.  This denormalization was present in ACS 4.2.

My thinking has been ... why not recognize the fact that this denormalization is set in cement, because permissions won't scale without it (even with my changes to other parts of the datamodel)?  Then provide explicit API calls to flip security_inherit_p or to change the permissions context of an object?

We'd rid acs_objects of two unneeded columns (unneeded because of the denormalization) and forcing code to use an API rather than bash objects directly would make it relatively easy to enforce a convention that we do it via Tcl API ... which leads us further down the path towards a permissions API which is safe for caching ...

Then let's put in a real parent_id column - removing the then redundant parent_id column from content_item.

I think we could get away with setting the new parent_id column to the current context_id value (except for content_items which would get the existing parent_id.)  None-content objects are already frequently using this field for that purpose, and if code isn't doing so it wouldn't be hurt by it because it would be "blind" to context_id.

This is a fairly radical change but long-term would remove the temptation to use context_id as a parent_id without adding any additional bytes to an object.  And future packages would benefit from having an unambigious column available for recording object parent-child relationships.

I also think we should put package_id in basic objects.  My objections to some of the extra columns proposed by Dirk Gomez don't extend to package_id as tracking content by package is a requirement for subsite-aware packages.

• I create a notes table. Each record in the notes table is also an ACS object. In which field in which table should I store the note owner? The package instance the note is in?
• I create a new permission for notes, e.g. "generate-email-alert". How do I indicate who does and does not have this permission for this note?
• What is this "denormalization?"

I will give it a shot and try to answer your three points above.

- The id of the user, or prehaps better, the party that owns the note should be recorded in a "owner_id" column in the notes table if you want to be able to change the assigned user. OTOH, if ownership doesn't ever need to be passed to anyone else but the user who created the note, it is probably okay to just join against acs_objects if you need to show that information.

- What you create is a "privilege". It's not entirely clear to me what the distinction between a privilege and a permission is ... I would like to express it as: "You grant the permission to exercise privilege X on object Y to party Z." However, that may be a bad interpretation and is certainly beside the point ...

The /permissions/ page is one place you can grant permissions. You may also do it directly from PL[PG]SQL when you create an object, for instance. Just use "acs_permission__grant_permission".

- An example of denormalization would be if one (as Barry proposes) would move the "object_type" column out of the acs_objects table and maintain the various object_types in a separate table (coincidentally such a table already exists) with (say) object_type_id as primary key. The removed column would be replaced by a "object_type_id" column pointing to the separate table.

At least this is my understanding of "denormalization". Someone please correct me if I'm wrong.

/Ola

The current documentation says:

Try not to write queries in your application that join against acs_objects. This means you should never use the fields in acs_objects for application-specific purposes. This is especially true for the context_id field.

Why not?

Also, it's critical to separate the semantics of the core from the semantica of the app, because if you don't, then your application breaks when the core changes. Might that happen anyway? Sure. But you protect yourself better if you apply the software engineering concepts of information hiding and factoring to your code.

If you allow the core to hide its information and redundantly store it yourself, what you get is much more freedom from breakage, because you have separated the issues of your app from being affected by issues of the core.

If you have your app's procs and other entities factored properly, then even if you do experience breakage, you don't have as much work to do to unbreak it, since the breakage is likely factored into only one place.

If you are going to assume some non-standard interpretation of an acs_objects field, then don't join, store yourself instead.

On the other hand, if you -strictly- interpret fields in acs_objects according to the original meaning and intent, then a join is ok. This means avoiding application-specific interpretations entirely.

This is going to hold true so long as you believe your interpretation of acs_objects field values will continue to hold over the life of the app.

Many people are advocating quick changes to the data model, a surefire way to keep the core unstable. On top of that, interpretations on fields in acs_objects, once correct assumptions, could become package breakers, as a result of changes in how data in core tables is expected to be interpreted.

Lack of maintained documentation will extend that effect over the entire time docs continue to be ignored: if you can't find out the correct way to interpret fields in tables you don't create, how can you build anything that uses those tables and have a reasonable expectation it will work?

What I've said for the acs_objects table holds true for all other tables in the core kernel, and really for any table that you did not create.

Sorry folks!

Thanks for correcting me, Carl.