You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Si Chen <si...@opensourcestrategies.com> on 2007/01/23 02:31:59 UTC

Re: svn commit: r498877 - /ofbiz/trunk/applications/content/entitydef/entitymodel.xml

David E. Jones wrote:
>
> Wouldn't it be better if it was just null if we don't know the mime 
> type? Where would a mime type that isn't in the database come from 
> anyway?
>
> -David
>
>
> On Jan 22, 2007, at 5:47 PM, sichen@apache.org wrote:
>
>> Author: sichen
>> Date: Mon Jan 22 16:47:34 2007
>> New Revision: 498877
>>
>> URL: http://svn.apache.org/viewvc?view=rev&rev=498877
>> Log:
>> Removing fk constraint on Content and DataResource.  This constraint 
>> is a bad idea because mime types are open ended.  Fixes bug where 
>> attempting to upload esoteric files like .patch files would crash 
>> because the MimeType isn't there.
>>
>> Modified:
>>     ofbiz/trunk/applications/content/entitydef/entitymodel.xml
>>
>> Modified: ofbiz/trunk/applications/content/entitydef/entitymodel.xml
>> URL: 
>> http://svn.apache.org/viewvc/ofbiz/trunk/applications/content/entitydef/entitymodel.xml?view=diff&rev=498877&r1=498876&r2=498877 
>>
>> ============================================================================== 
>>
>> --- ofbiz/trunk/applications/content/entitydef/entitymodel.xml 
>> (original)
>> +++ ofbiz/trunk/applications/content/entitydef/entitymodel.xml Mon 
>> Jan 22 16:47:34 2007
>> @@ -114,7 +114,7 @@
>>        <relation type="one" fk-name="CONTENT_PRIVENM" 
>> title="Privilege" rel-entity-name="Enumeration">
>>          <key-map field-name="privilegeEnumId" rel-field-name="enumId"/>
>>        </relation>
>> -      <relation type="one" fk-name="CONTENT_MMTP" 
>> rel-entity-name="MimeType">
>> +      <relation type="one-nofk" rel-entity-name="MimeType">
>>          <key-map field-name="mimeTypeId"/>
>>        </relation>
>>        <relation type="one" fk-name="CONTENT_CHST" 
>> rel-entity-name="CharacterSet">
>> @@ -757,7 +757,7 @@
>>        <relation type="one" fk-name="DATA_REC_DTSRC" 
>> rel-entity-name="DataSource">
>>          <key-map field-name="dataSourceId"/>
>>        </relation>
>> -      <relation type="one" fk-name="DATA_REC_MMTP" 
>> rel-entity-name="MimeType">
>> +      <relation type="one-nofk" rel-entity-name="MimeType">
>>          <key-map field-name="mimeTypeId"/>
>>        </relation>
>>        <relation type="one" fk-name="DATA_REC_CHST" 
>> rel-entity-name="CharacterSet">
>>
>>
>
If we didn't know the mime type the download servlet might complain.  
The mime type also might be nice to know somewhere else down the road.

I guess the problem seems to be this: there are many many potential mime 
types.  If we maintained an ofbiz table of all the mime types and only 
accepted content of a "known" mime type, then it seemed to me that we'd 
be struggling to keep up with all the new stuff created on the web 
everyday.  I didn't see what the benefit of that would be, but I do 
think if it's an unknown mime type, chances are whoever created a file 
of that type would know what to do with it.