Forum OpenACS Improvement Proposals (TIPs): TIP#30: (Approved) Revise file-storage data model to use the content repository correctly

TIP: 30
Title: Revise file-storage data model to use the content repository correctly
State: Draft
Type: Project
OpenACS-Version: 5.1
Vote: Pending
Created: Friday, 14 November 2003


In the existing file-storage data model is inconsistent with the documented usage of the Content Repository and causes problems when URL is calculated to support pretty URLs, bulk-upload of relativly linked HTML files and images, or WebDAV support.

Current Implementation

In the file-storage create script attribute is used to store a pretty title for a file-storage object, while the filename of the uploaded file is stored in cr_revisions.title. When a file is uploaded the filename is stored in cr_revisions.title and the user supplied title is stored in When a new revision is uploaded, the title is not stored as a versioned attribute and the filename of the uploaded file is saved in the new cr_revision object created. In the current 5.0 version of file-storage an index.vuh file under file-storage /www/view/ tries to provide a consistent URL for files that does not rely on the revision_id of the live revision of the file-storage object. This relies on the user of the package to type in the title the same as the filename.

Proposed Change

This TIP proposes to change the datamodel so that the filename is stored with the cr_item. If a file with a different filename is uploaded it is stored as a seperate cr_item. To convert existing file-storage objects, the filename of the live revision will be copied to, and will be copied to the title attribute of the live revision. As there is no way to store versions of a title in file-storage any previous revisions of existing files will retain the upload filename as their title. Upgrade scripts will be provided. In addition I will backport these changes and create a file-storage version with the fixes that will run on an OpenACS 4.6.3 based system.

I forgot to add some information:

Additional Items

The file-storage root folders for each package instance are named file-storage_object_id and are all created with parent_id of -100. To generate a URL from the root folder the name needs to be the URL fragment of the site node where the file-storage package instance is mounted. To make this work the parent_id will have to be changed.

The Add a Revision behavior will not be changed. A user will be able to add a new reivison to an existing item where the client filename of the upload is different from the existing item.

What a thrill this package is, eh? ;-)

I totally agree with the suggested swap of and revision.title attributes - the current implementation is indeed bizarre. But didn't it in fact become this bizarre because developers have been trying to adapt to the even more fundamentally bizarre current "Add a Revision" behavior:

When you upload a file, why must it then be possible to upload *another* file and call it a revision of the first file instead of just calling it another file? If you really want to upload a revision of a file, then it would seem rather natural to upload an edited version of the same file (having the same name, per definition) ...

If we could make file storage resemble a traditional file system, with the additional features of revisioning and the ability to give the revisions titles and descriptions, the package would seem more logical to users and developers alike, IMHO.

Just a minor clarification:

"This relies on the user of the package to type in the title the same as the filename."

It's true that the title has to be the same as the file name when you upload a file and you want to have relative linking functioning, but you don't actually have to type the title. If you leave it blank the title becomes the same as the file name.

Ola, Thanks :) I didn't try uploading a file without a title. That is good to know.

Regarding the "Add a revision" function, at least some of the existing file-storage users make use of the function, so it will stay in, but I expect most users to use it more like a traditional filesystem.

Posted by Lars Pind on
Approved. Go for it.
Its been up for a week and I approve too so it's official