Forum OpenACS Development: Add New Group Type is broken under PG

I'm running a dual Oracle/PG setup with the latest version from CVS.
During testing I noticed that the site admin feature Add New Group
Type was choking.  The reason appears to be that the (Oracle-
specific) "Connect by" query "select_group_supertypes" has not been

I know there is still work going on--I mention this only because the
code in question resides in the acs-subsite package (new.tcl) which
is listed as Ported in the status report document...

(This feature appears to function properly under Oracle)

Posted by Dave Manginelli on
I just realized that new.tcl is not very descriptive...
The file in question is actually:
Posted by Steve Woodcock on
Yes, status report is inaccurate. Should say ~50% complete.

There's more to the problem than just a connect by query -- if you follow the code, it executes group_type::new which (amongst other things) causes a new PL/SQL package to be created for the group type. This uses Oracle internal user_arguments and user_objects views which don't have a handy PG equivalent.

I have got group_type::new working in my CVS, but it involves parsing PL/PGSQL source code to extract information provided in the Oracle user_arguments view. I need to look at the rest of the PL/SQL manipulation that's going on with this module and come up with a satisfactory porting solution but I've been too busy lately.

Excepting this package stuff, the outstanding unported queries are all fairly similar/trivial as far as I can remember.

Hope this sheds some light.

Posted by Dan Wickstrom on
I didn't know that acs-subsite was not ported yet.  I'll change the status.
Posted by Dave Manginelli on
Thanks for the info, Steve.

I'm not an ACS expert but I am pretty good at SQL.  If there's anything I can do to help with the port and/or testing (of the subsites package) please let me know.  (You can e-mail me the specifics off-list).

Posted by Luke Pond on
There is an extensive amount of code in the acs-subsite package that was added for ACS 4.2. The Oracle-specific code Steve refers to is part of a UI for extending group types and presenting forms to edit attributes attached to user-group relationships. This was intended for use by the new intranet package that Michael Bryzek and others were working on.

I believe this functionality is extremely important, and is a good example of the cool things that the ACS 4 data model was designed to support. But it may need a significant redesign or code cleanup in order to be successfully ported. Steve, can you tell us the current status of this package and let us know if you need any help?

Posted by Stephen . on
I believe this functionality is extremely important, and is a good example of the cool things that the ACS 4 data model was designed to support.

Well, kind of. It's designed to support runtime addition of attributes to objects, but it doesn't quite work, which is why this custom solution for groups and group_types was added in 4.2. Ideally this core service would be fixed and expanded (object types could themselves be objects, enabling runtime addition of attributes to object types without DDL) so that all modules can take advantage.

Posted by Don Baccus on
As it happens Steve, DanW and I have had a brief e-mail discussion about this over the past day (Ben's off playing with his laptop on some airplane again).

We're leaning towards augmenting the metadata datamodel with sufficient information to implement this functionality without dependence on the RDBMS's own metadata (in particular Oracle's
"user arguments" view which can't be recreated from the PG system tables and which would be a potential porting hassle for other RDBMS's
as well).

Comments?  It seems to us that this would provide us a somewhat RDBMS-independent framework for dealing with this code, though the details will differ for each RDMBS's programmatic language's syntax and semantics.

If we do this, package porters will have to initialize the necessary metadata.  Since the code inherited from aD is very inconsistent as to the extent to which packages initialize their package metadata, I was thinking this might be a good time to clean up these loose ends as well.

Steve's looking into more deeply into this approach soon (this weekend, perhaps?) so there should be more information before long, maybe even completion of implementation.

Posted by Stephen . on
In what ways are you considering changing the metadata model? Are you considering only a fix to the immediate problem with the groups system?

The ACS4 requirements and design docs talk about 'modifiable data models' but the implementation seems incomplete. For example, one of the goals of such a system should be to illiminate DDL at runtime. However the acs_object_types table has not null and unique constraints on table_name, which forces a new table to created for each new object type whether it's needed or not.

Object types themselves are not acs objects, so custom attributes can only be associated with specific instances of objects, not every instance of an object type, which is the more useful scenario. When you have users creating new object types from a web interface, you start to want to use the permissions system, again requiring object types be acs objetcs.

I think the lack of this working feature is quite an impediment to the system. It should be used by many modules e.g. groups, ecommerce, simple-survey, cms, but instead each module has to re-invent it's own solution.

Obviously you're on a schedule so I don't know what it makes sense to do before launch.

Posted by Don Baccus on
Unfortunately, I think we only have time to implement a fix to this specific problem at the moment.

However, when I first read the acs_objects datamodel one of the first things that struck me was the fact that object types ain't objects.  So I find your comment regarding this very interesting and it confirms my  gut feeling that flexibilty has been lost because of this decision.

I don't know what your personal schedule is like, but down the line this issue is something that clearly should be looked into.  As time goes on I think we'll identify a considerable number of core design issues that are worth analyzing with an eye to improving the system.  It would be great to have a small group of folks who have experience with the 4.x guts take on this task.

I'm definitely thinking in terms of the future, perhaps fall or early winter, as a time to consider reviewing the basic design of objects, permissions, and other core "stuff".