Forum OpenACS Development: How is the cr_mime_types designed

Collapse
1: How is the cr_mime_types designed
Posted by Deds Castillo on 09/18/02 06:25 AM
How should the cr_mime_types be used?  How are several extensions
mapped to a single type?  I've noticed that the mime_type column is a
primary key preventing duplication.  Does this mean that the
file_extension column should contain all the possible extensions
separated by something?
Collapse
2: Response to How is the cr_mime_types designed (response to 1)
Posted by Dan Wickstrom on 09/18/02 03:05 PM
It appears that it was designed to only support one file extension per mime type. It probably would be better to change cr_mime_types to have a composite primary key consisting of the mime type and the file extension. Such a change would require minor modifications to the following packages:

  • acs-content-repository
  • bboard
  • cms
  • cms-news-demo
  • download
  • file-storage
  • general-comments
  • photo-album
  • ticket-tracker-lite
  • wp-slim

What is the problem that you're trying to solve?

Collapse
3: Response to How is the cr_mime_types designed (response to 1)
Posted by Jeff Davis on 09/18/02 03:21 PM
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.

Collapse
4: Response to How is the cr_mime_types designed (response to 1)
Posted by Deds Castillo on 09/18/02 03:59 PM
I agree.  There's really no problem I'm trying to solve.  It's just that changes have been committed to CVS head which affects file-storage because of the limitation on cr_mime_types.  I previously submitted a patch here https://openacs.org/bboard/q-and-a-fetch-msg.tcl?msg_id=0006HQ&topic_id=14&topic=OpenACS%204%2e0%20Testing before studying cr_mime_types relation, with the modules that depend on it, in-depth.  But now that Dan has explained it I guess that patch is the wrong way to go as it's still broken because of the cr_mime_types limitation.  Anyway I've just reverted to an older version of the file-strorage-procs.{xql|tcl} to make it work.
Collapse
5: Response to How is the cr_mime_types designed (response to 1)
Posted by Dan Wickstrom on 09/18/02 04:14 PM
Jeff, yes I think your approach is better than using composite keys.  Would you be able to change this for the 4.7 release?
Collapse
6: Response to How is the cr_mime_types designed (response to 1)
Posted by Jeff Davis on 09/18/02 04:18 PM
Dan, I think it should not be a problem for 4.7 and even for 4.6
if someone else wants to do it :).
Collapse
7: Response to How is the cr_mime_types designed (response to 1)
Posted by Dan Wickstrom on 09/18/02 05:11 PM
That's usually the problem.  Probably everybody else is occupied with other things related to the 4.6 release, so unless you find time to make the changes, it probably won't make it into this release.
Collapse
8: Response to How is the cr_mime_types designed (response to 1)
Posted by Jun Yamog on 09/18/02 07:49 PM
I can take in ticket-tracker-lite since I made the dependency anyway.  File-storage too if DonB is too busy.  Maybe CR but that is bit too big and I think its in better hands with DanW.  The other packages I am not familiar with.  Maybe bboards but I don't like the code of bboards.

DanW,

If you have decided what to do even if you haven't committed anything yet just ping me.  So I can have the patch ready when you commit the changes.

Collapse
9: Response to How is the cr_mime_types designed (response to 1)
Posted by Dan Wickstrom on 09/19/02 04:39 PM
Jun, you just need to coordinate the changes with Jeff, when he updates the cr mime data model.
Collapse
10: Re: How is the cr_mime_types designed (response to 1)
Posted by Dave Bauer on 12/19/02 10:10 PM
What if a file has no extension?
Collapse
11: Re: How is the cr_mime_types designed (response to 1)
Posted by Jun Yamog on 12/20/02 02:55 AM
Dave,

In putting in data it depends on how you check it.  Do you check by extension or my its reported mime type.  If you check it by extension then you will need a correct extension when you upload the file.

Serving the file is irrelevant.  What is in cr_revisions.mime_type will be followed irregardless if you have the correct extension or no extension at all.

I haven't check how template::bah_forgot determines the mime, but that is what I use to check an incoming file mime type.

Jeff,

Has the correction in the cr_mime_types done?  If yes then I better get ticket tracker lite into shape.