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.

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*

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.

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 ...

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.