Forum OpenACS Development: Finding the package_id for cr_items

Collapse
Posted by Jarkko Laine on
I'm writing a small includable snippet for Photo Album that outputs a random photo and a link to the corresponding photo album page.

I want to make it subsite-aware so that user can define url="/photos1" in the include tag and then get the photo from only photos under that photo album instance. The problem is that I can't find an easy way to tie individual cr items (i.e. photos) to a package. The only place in content repository having a package_id field is cr_folders and even there, the field is empty for all photo album instances (folders and albums).

Even if the package_id field were there, we'd only be interested in the package id of the Photo Album root id, so we'd probably need to make a recursive query or a view to get the id we want.

I of course hope there's some easier way that I haven't found. Hopefully someone could help me on this.

Collapse
Posted by Robert Locke on
Hi Jarkko,

There is a table called "pa_package_root_folder_map" which links the photo-album package_id to a folder_id, which I imagine you could then link to the photos contained in that folder.  (I'm not sure why the package_id column of cr_folders was not used.  Perhaps the author was not aware of its existence.)

What happens if you don't include the "url" parameter?  Or is it required?  If not, maybe it could include a random photo from any installed photo album site-wide or subsite-wide.  Just a suggestion.

Thanks for taking on this work...

Collapse
Posted by Jarkko Laine on
Hi Robert,

And thanks, I'll take a look at pa_package_root_folder_map.

The url parameter is optional and if let away defaults to all package instances (of the whole site at this point). I think that's good enough in most occasions and at least the query should be *fast* :-)

Collapse
Posted by Dave Bauer on
Jarkko,

I recommend adding a package_id column to pa_photos. Right now each package maintains the package_id information in the object_type specific table. There has been discussion about moving package_id to acs_objects, but that really won't make your job any easier. Your code is photo-album specific and is free to have knowledge of the photo-album data model.

There also might be other photo-album tables that might need package_id added, I didn't look any further.

Collapse
Posted by Don Baccus on
I agree with Dave.  We may put package_id into acs_objects as early as 5.0 depending on how much other stuff we take on (we need to finish 5.0 by mid-summer because a couple of universities are heavily invested in seeing .LRN 2.0 work by fall.)

Upgrade scripts to copy package-specific datamodel package_id columns into an acs_object package_id column will be very easy to write, PG now has DROP COLUMN so that will work, too, and hacking the relevant queries will be easy enough.

Collapse
Posted by Dirk Gomez on
Don, could you post a list of packages that need to be worked on - ordered by importance, so that we can concentrate on getting the most important packages to work with 5.0.
Collapse
Posted by Don Baccus on
Yes, I plan to work on a 5.0 project plan after I get back from a short trip this week and 4.6.3 final is released ...
Collapse
Posted by Timo Hentschel on
It's excellent to put package_id where it really belongs - acs_objects. But please, while you're at it, why not also adding named_objects to 5.0? I know, we haven't been able to resolve the i18n issues, but we won't solve all the problems in one day...
Collapse
Posted by Don Baccus on
I think we need to discuss putting named objects in 5.0.  We need to study the impact on existing packages.  Will they be invisible to packages that don't care about names now? Can we delay modifying individual packages to be derived from named_objects until later?

Unfortunately (or, I suppose, fortunately depending on who is reading this) 5.0 is going to be driven by its delivery date.  We need a beta release fairly early in July.  This date's driven by .LRN 2.0, because the University of Heidelberg's committed to using .LRN 2.0 this fall, and they've provided most of the funding for localization and external authentication that they need in order to use it.  They've helped fund the project so we need to perform and deliver them  useful software in the timeframe previously agreed to.

If named objects can't slip in invisibly, I don't forsee us having the time to rewrite all our standard packages (and to provide upgrade scripts) in the given timeframe.  Keep in mind we've committed ourselves to another needed big-time change: the NOQUOTE patch.  We'd put this one off for at least a year so, if endless delay times are some sort of qualification criteria, NOQUOTE "deserved" to be slotted ahead of named objects.

Timo - if you want to write up some thoughts about how we might slip in named objects in the given timeframe, feel free and I'll also look into it.

Worst case is we push for named objects in 5.1 in, say, late summer early fall (release, we'd shove it into HEAD earlier.)  I do believe this is the right approach, it's just a matter of timing and schedule.

Collapse
Posted by Jun Yamog on
Hi,

Just going over old emails.  I think it would be nice not to bind content items to a particular package.  I think its very useful that different packages can use the same data.  CR is like a central repository.  So different apps should be able to access its data.  So cr_folders.package_id does not seem to be good.  I use to think having this was great when using ETP.  But now I think ETP should have just had a mapping table to what folder it was using.

Anyway just my opinion.