Forum OpenACS Development: Response to How is the cr_mime

I have an uncommitted change from sloan for cr_mime_types which removes the primary key from mime_type and creates it on extension. is also fixes the maybe_create_mime_type function for file storage an some other stuff. I think it is not strictly the right answer but it does not seem to break anything.

Ideally we would not duplicate label when we add an extension -> mime_type mapping. so the model would look like

cr_mime_type_descriptions ( 
  mime_type primary key
  label );

cr_extension_mime_type_map (
   extension primary key,
   mime_type references cr_mime_type_descriptions,
);

and cr_mime_types would be a natural join on those two.

I just don't think I will be able to get this in before 4.6 and the sloan answer is a reasonable compromise for now.

I don't think you want a composite key since I think if you start mapping a single extension to multiple mime types you will be in a world of hurt.

Forum OpenACS Development: Response to How is the cr_mime_types designed