Forum OpenACS Development: File storage root folders have parent_id set to -100, is it necessary?

File storage root folders for each package instance have -100 (the default content folder) set for the parent_id.

Right now each cr_item.name for these folders is file-storage_package_id where package_id is the object_id of the package instance.

To make WebDAV work, the folder should be the same name as the  site-node (at least it makes the URL consistent).

I am pretty sure dotLRN at least, sets all file-storage instances to the same name, so having all of the folders named for the site node with the same parent won't work.

I think that parent_id can be NULL for these items without causing any problem or changing the behavior of the package.

If that doesn't work or isn't recommended, I'll create a default root for all file-storage instances, but I don't think this is actually necessary.

Hi Dave,

I guess its ok.  But maybe code that uses parent_id to traverse a path may end up with a null root rather than the cr root folder.  Although I am not familiar of any, but maybe some oracle code?  Since pg code tend to use the tree_sortkey.  But maybe a oracle code perhaps?

Creating a default root for fs maybe a safer option, but then again a whole lot of work and upgrade script.

Just afraid that making parent_id null may make it semantically incorrect.

It is flat out wrong to have parent_id set to -100, one of several things that needs fixing in file storage.  It means that mounting file storage under a subsite results in permission inherited from node -100, which makes more sense.

This has been on my personal hit list of things to fix but I didn't get to it for 5.0.

.LRN renames folders for file storage to names related to the class or community.

Setting parent_id to NULL isn't right either but maybe is necessary given the fact that the parent_id is assumed to be a folder ...

Ok good :) I think it is ok to use NULL are parent_id. That means it is the start of a serperate folder hierarchy and it allowed according to the content repository documentation (which is definitely out of date).

Actually cr_items.parent_id is definied not null. It doesn't have a constraint on it and it assumes items with no parent have parent_id of 0.

Maybe this is what seems wrong?

I'll have to look into this, and I might just create a root folder for all file-storage instances if I can't figure it out quickly.

Well ... it doesn't want to be zero, that's for sure.  This sounds like a wart left over from the CMS->ACS integration effort.

I think NULL's OK and PG 7.3 supports the removal of this constraint, doesn't it?  And we're requiring 7.3 for 5.0 and since I assume your change is for 5.1 (since 5.0's a freeze) then you'll be able to generate an upgrade script.

Note that this is a TIP item ... you don't just get to do it yourself, it's a fairly significant change.

Don,

It sure is a big change. I wanted to get some advice so I would know what to put into a TIP.

Maybe I should make that more clear in my initial post.

I have decided that creating a content item for every different named revision is the wrong solution. I think using the filename of the live revision for the content item is the best solution. This way only the title/name of the live revision will be swapped and users who upload files will not be required to type in the filename as the title to make relative links work. This will definitely make it easier to support bulk-upload.

Dirk reminded me that on Oracle, NULLs are not indexed so that is probably why parent_id can not be NULL. As parent_id is supposed to point to a content_item, using 0 for an item with no parent is not really correct either.

More thinking is required. Any ideas?

Your other option of making a folder for all file storage maybe the hard option but maybe the only viable one.  Although not sure about the permissions which has been brought up by Don.