Forum OpenACS Improvement Proposals (TIPs): Re: TIP #132 Plans to address storage_type problem in CR

Collapse
Posted by Dave Bauer on
Michael my objection to this change is explained right here
" It turned out that our instance was originally set up to store files in the DB and even though all newer versions of the portrait upload code explicitly use the file system, the storage_type column in cr_items was not being changed appropriately. "

There is a bug in the portrait code. It should respect the storage type of the cr_item when adding a new revision. If it doesn't that is where the problem is. So hacking the content repository to change the storage type when you change the live revision does not even solve your problem. It only masks the problem. Code that allows viewing of non-live revisions will still break. The only sane solution right now is to make sure all revisions use the same storage type.

To fix your problem with portraits, I suggest deleting all the old revisions, and fixing the storage type to match the latest revision. Since portraits don't support accesing the old revisions this should not affect the user at all.

Although logically, I understand why storage_type belongs with the cr_revision, I can't see any practical reason to store different revisions of one cr_item as different storage types. I think the real fix is to make sure, once the item is created, all subsequent revisions have the same storage type.