Forum OpenACS Development: Subsite Strange Behavior (Cross-post)

Request notifications

Posted by Dave Manginelli on
I initially posted this on the Testing forum, but I believe it
deserves a larger audience than that, so I'm repeating it here.

I'm using the 4.5 beta release from CVS as of about 1 week ago.

This problem is observed when I create two subfolders of the main
site, say foo1 and foo2, and then mount an instance of Subsite at each
folder (using the "New Application" option).

When the first instance is mounted, OACS appropriately creates an
application group for the subsite and an apm_package instance of
acs-subsite.  However, when the second instance is mounted (foo2),
OACS does all of the above PLUS creates a composition relation between
the foo1 and foo2 application groups.

This seems incorrect to me.  These subsites are at the same "level."

Why should one be "composed" of the other just because one was mounted
before the other?  (Note: I specified the "New Application" mounting
method both times)

Additonally, I notice that if I visit the group admin pages for the
site and subsites I can only "see" the following groups defined:

At Main Site Group Admin: No Groups Defined

At Foo1 Group Admin: Main Site Parties, Foo2 Subsite Parties

At Foo2 Group Admin: No Groups Defined

I would have thought that ALL groups would have been visible from the
Main Site admin pages.

It looks to me like maybe the subsite code is assigning the "reverse"
of the relations that it should be but I hope that someone who is up
on this will comment...

Posted by Jun Yamog on
This may not really help.  But I find those group admin pages to be either not working or is not showing the correct data.  Normally what I do is just invoke the db API for relationship and groups.  I also check the groups and relations table to see what I have done.

Try to check out the tables, I have doubts on those group admin pages.

Posted by Dave Manginelli on
Thanks Jun.  I think you are right that the group admin pages are lacking, but in this case I have verified that the fault really is in what's being done to the underlying tables.

For now, I'm going to abandon any reliance on the application_group stuff and scope my subsite by adding a package_id column to my data to distinguish which subsite it "belongs" to.  It will be less flexible than using application_groups but a) I can understand it, and b) I'm not enough of an expert to fix the Subsite code.

This solution was recommended in this old AD thread (at the very bottom):

It also points out the limitations of the package_id approach.  Since there's no mention of application_groups, I'm assuming that this discussion came along before that notion was introduced.  Especially because the application_group scheme (if properly implemented) could elegantly solve some of the context_id/permissions problems that are discussed there.

Posted by Dave Manginelli on
I'm amazed that only Jun (who's mentioned similar, potentially related, issues in his own thread) has responded to this question/issue.  I would think that Subsite functionality is of interest to lots of folks and that at least a few pioneers are actually using it.

As I mentioned previously, I am using the 4.5 beta from CVS as of about a week ago, and I'm using Postgres (7.2).  I have examined the SQL logs and the tables and I really believe that there's a problem in (at least) how the subsite application groups are being created--not just in the groups user interface (as Jun observed) where they are displayed.  Would it be of benefit to the community if I posted the table dumps or relevant SQL snippets from the logs?

Even if everyone thinks the subsite code is working fine and I'm just a a newbie without a clue that information would be useful to me.


Posted by Don Baccus on
Sorry ... I've been really busy with client work and haven't had time to take a look at your subsites issues.  I know a lot of other folks are really busy at the moment, too ... unfortunately the toolkit's gotten to the point where a fair number of people are using it to build sites for customers.

I should've held off on starting this release process for another six months, then people would be afraid to use it and volunteering for openacs instead! :)

(I'm just joking!  Honest!)

I hope to find time this weekend to take a look, myself.  My first check will be to make sure that the Oracle and PG version work the same way.  I'm assuming you use PG?

If I'm right (you're using PG) and the Oracle and PG versions show differing behavior, then we have a porting bug.  If the Oracle and PG versions show the same behavior then it sounds as though there are some design flaws.

Not too many folks are using acs-subsite AFAICT.  It's a very useful feature and we need to make it work right, certainly, but ... relatively few sites need full subsiting.  I think once people start playing with acs-subsite (when it works better, anyway!) they'll start thinking up novel ways of using it but thus far it's not been heavily used.

Posted by Dave Manginelli on
Thanks for the response, Don.

Yes, I'm using Postgres.

If there's any additional information that you would like me to provide you with (either on or off list), I would be happy to get it to you.

Posted by Don Baccus on
My first plan of attack will be to look at Oracle and PG behavior to see if they match, then, thanks ... if I need more info I'll post here.
Posted by Roger Williams on
I have seen this behavior as well. I believe this is a problem with *both* the underlying tables and the UI. Sorry that I cannot post the fix however.


Posted by Don Baccus on
OK ... I've dug into this and I've hit the jackpot ... Oracle and PG *both* fail, but in different ways and for different reasons ...

1. The Oracle version inserts the new group but it doesn't show up in the "group element map" view and views built on it, which means you can't see it from the UI (this may explain Jun's impression that the UI is broken and that you need to check the underlying tables themselves).

2. Dave's diagnosed the PG version correctly ... there's a tree query that looks like it might've gotten inverted when it was ported to PG.  This is easy to do using our tree keys, though there are now some easy ways to find parent nodes.  I need to look at the original Oracle query, too, I think it might be more complex than is required but until I fix #1 I'll leave that.

I won't be fixing these problems immediately but will try to do so in the next couple of days.

Posted by Dave Manginelli on
Thanks for following up on this, Don.

It would be great if you could post something to the list when you've had a chance to address this (or point me to an SDM link if I should be looking there...)

Thanks again.

Posted by Don Baccus on
I've made my first round of fixes which causes the group hierarchies to be built correctly.  The Oracle version worked for subsites mounted below the main site (because the "find the parent" query, though incorrect, was at least incorrect in a way that always returned the main site node).  The PG version was mostly just backwards.

There was also a cart-before-the-horse problem in the subsite mounting code that caused the corrected queries for both RDBMSs to fail.  This had been masked in the Oracle version by the bug that caused it to always return the main site node.

Now that the application groups and the composition relationships are being built correctly I see that the site map page in PG is incorrect, and adding users doesn't seem to work.  I haven't checked the Oracle version yet.

I've been very busy this week with client work so haven't had time to get back to it.  My plan is to spend part of tomorrow (Sunday) plugging away at Phase II Phixing...

I've been holding off on committing until I have something that works more or less coherently.

Posted by Don Baccus on
OK I spent some time on subsite issues yesterday, but didn't finish.

The Oracle version seems to work though I've not committed my changes yet.  You can create subsites and add members to them.  There's no way for a user to join a subsite membership group themselves though.  There's a "user-join" script but it's never called anywhere, and I've not tested it.  In theory you could add a link to this script to the acs-subsite index page and enable the feature.

The PG version is failing because of what appears to be a broken port of a very complex view in the relations code.  I'll be taking a look at this in the next few days.

Both versions of acs-subsite appear to have one serious scalabilty issue.  The query that pulls up the list of users which an admin can add as members to a site looks like it will run very slow as the site grows.  This needs to be investigated further.  On the other hand, basic membership checks and the like should be fine.

Posted by Dave Manginelli on
Don, I know you aren't finished with this, but I'm wondering if you would be willing to post the changes you've made so far.  Even if it's incomplete, any improvement at all would me move ahead a great deal.
Posted by Don Baccus on
I will commit changes over the weekend, how's that?  I've been extremely busy this week and haven't been able to get back to acs-subsite, but plan on setting aside another day this weekend to work on it.

I need to make sure that whatever I commit is consistent, i.e. do a little testing, even if I don't find the time to fix the errant view this weekend (I think I'll be able to fix it, too, though).

Posted by Don Baccus on
Dave ... if you're up to some hairy query hacking and want to take a look, "rc_parties_in_required_segs" in "acs-kernel/sql/postgresql/rel-constraints-create.sql" appears to be the view that's giving incorrect results.

Let me know if you're going to dig into this so we can coordinate our efforts.

If you don't have time or feel a bit overwhelmed by the view and the views it depends on that's fine, just thought I'd give you (or anyone else who's interested) a pointer to the problem.

Posted by Dave Manginelli on
Thanks Don, that would be great!

I know that "putting food on table" comes first, and I appreciate the time you've spent working on this.

Posted by Dave Manginelli on
Our posts crossed...

WRT the query: rc_parties_in_required_segs.

I'll try to "pull my own weight" on this by having a look at it.  However, I've had a lot of trouble so far just inferring what the system is _supposed_ to do well enough to know when it's working/not working...  I'll try to determine the query's purpose from the context but if you feel like mailing me a one or two sentence description that might make it easier for me.

Thanks again for your work on this.

Posted by Don Baccus on
OK, I've fixed the view that was failing and have committed my changes.  The Oracle and PG versions seem to work equivalently now.

I disabled "user_profiles" in PG, as it was disabled in the Oracle version.  It's in a state of disarray and I'm not sure I like the basic approach (user profiles are a special kind of membership relationship, which mean they show up in the group admin pages).