Forum OpenACS Development: Proposal for APMs for openACS?

Posted by Peter Vessenes on
I've heard rumors that the APMs will allow side-by-side openACS and ACS Classic code. Is this true? If it is, I can't find it anywhere. If not, could we start a discussion about what the enhanced APM structure should be like?

Ybos would love to have one codebase for both systems, and we've started rolling out ACS 4.0 modules, so we have some experience, and opinions about this. But, I don't want to jump the gun, if you all are not quite ready to talk about this stuff.

Posted by Bryan Quinn on
There is a section in the APM specification file that specifies what database the package supports.  However, there is no mechanism to determine which SQL to use.  I would like to add support to APM to support multiple databases.  What we need to accomplish this is a database abstraction mechanism.  All that I am aware of right now to accomplish this is statement names.
Posted by Dan Wickstrom on
You can also get access to the page that the proc is executing in by using info script command.  So for a tcl page you can uniquely reference a query using the combination of the page name and the statement name.  For tcl library procs, you could use the combination of the query statement name, and the tcl proc name to uniquely reference the query.
Posted by Ben Adida on
Before this goes into another db abstraction discussion, I would like to point out that the ACS/OpenACS shared viewpoint now is that true abstraction isn't going to happen (we've had a couple of meetings about this). SQL is already supposed to *be* an abstraction, and it's not implemented in a standard way from RDBMS to RDBMS. In terms of switching the SQL depending on what DB is being used, that is an issue being discussed in a separate thread.

The important point Peter raises here is the idea of "fat binary" APMs for OpenACS/ACS. I *absolutely* would like to see this happen in a way that is hopefully backwards compatible with current APM packages (for ACS classic). Basically, the package manager should be able to say "I am running on Postgres, and this package does have Postgres compatibility, so let me set up the Postgres data-model for it" and same thing with the same "fat binary" APM, but Oracle. We assume that a package that declares being Oracle *and* Postgres compatible will have both sets of data model files, and will follow whatever convention we come up with for replacing queries for one DB with queries for the other.

Backwards-compatibility, again, would be great. This means that while OpenACS would implement a slightly augmented, RDBMS-aware package manager, ACS Classic could look at a fat binary package and still find the correct Oracle data model files and all. This could be tricky, but is worth the effort to get single APMs.

Peter, since you and your team have looked at APMs already, can you propose a solution to this? Basically,