ImageDataResource, VideoDataResource, AudioDataResource, OtherDataResource

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Wai
Reply | Threaded
Open this post in threaded view
|

ImageDataResource, VideoDataResource, AudioDataResource, OtherDataResource

Wai
Hello All,

What is the purpose of having the following "separate" entities:

ImageDataResource
VideoDataResource
AudioDataResource
OtherDataResource

Couldn't all these entities be lumped into one, since they all store blobs and it is associated with the entity DataResource that specify a mimeType to identity it.

Was it designed this way to serve some specific purpose?

Thanks,
Wai
Wai
Reply | Threaded
Open this post in threaded view
|

Re: ImageDataResource, VideoDataResource, AudioDataResource, OtherDataResource

Wai
Hello,
Anyone can comment on this?
Thanks,
Wai
Reply | Threaded
Open this post in threaded view
|

Re: ImageDataResource, VideoDataResource, AudioDataResource, OtherDataResource

Jacques Le Roux
Administrator
I guess the purpose was to separate those different types at a functional level

Jacques

From: "Wai" <[hidden email]>
> Hello,
> Anyone can comment on this?
> Thanks,
> Wai
>
> --
> View this message in context:
> http://ofbiz.135035.n4.nabble.com/ImageDataResource-VideoDataResource-AudioDataResource-OtherDataResource-tp4354343p4362520.html
> Sent from the OFBiz - User mailing list archive at Nabble.com.
Wai
Reply | Threaded
Open this post in threaded view
|

Re: ImageDataResource, VideoDataResource, AudioDataResource, OtherDataResource

Wai
Hello,

I don't understand what useful functional purpose it would serve to separate these different types of blobs into the separate entities when DataResource.mimeTypeId/Content.mimeTypeId would help to distinguish one type of blob from another.

The complication with having separate entities for each type of uploaded binary files types is one of management.

For a scenario where a user stores a photo to the content component (which ends up storing the image data into DataResource and ImageDataResource).  Now, when the user decides later to change the content to another type of file (eg. a video file) for the same contentId, then ofbiz would have to make the necessary changes of destroying the entry in ImageDataResource and store the uploaded video data to VideoDataResource for the same DataResource.dataResourceId/Content.dataResourceId.  This is rather complicated for maintenance purposes.

I propose to only use ImageDataResource for storing any kind of blob content and rely on Content.mimeTypeId and/or DataResource.mimeTypeId to identify the format of the blob.  Hence deprecating VideoDataResource,AudioDataResource,OtherDataResource.

Any insight/comment is appreciated.

Thanks,
Wai
Reply | Threaded
Open this post in threaded view
|

Re: ImageDataResource, VideoDataResource, AudioDataResource, OtherDataResource

Bilgin Ibryam-2
Hi Wai,

On 9 February 2012 17:23, Wai <[hidden email]> wrote:
> Hello,
>
> I don't understand what useful functional purpose it would serve to separate
> these different types of blobs into the separate entities when
> DataResource.mimeTypeId/Content.mimeTypeId would help to distinguish one
> type of blob from another.

I cannot tell you the exact reason for these separate entities, but a
wild guess is that you can tune up these tables for each blob type.

I'm also curious about the original reasoning for this

>
> The complication with having separate entities for each type of uploaded
> binary files types is one of management.
>
> For a scenario where a user stores a photo to the content component (which
> ends up storing the image data into DataResource and ImageDataResource).
> Now, when the user decides later to change the content to another type of
> file (eg. a video file) for the same contentId, then ofbiz would have to
> make the necessary changes of destroying the entry in ImageDataResource and
> store the uploaded video data to VideoDataResource for the same
> DataResource.dataResourceId/Content.dataResourceId.  This is rather
> complicated for maintenance purposes.

Deleting from two tables is not much complicated than deleting from
one table with OFBiz ;)

>
> I propose to only use ImageDataResource for storing any kind of blob content
> and rely on Content.mimeTypeId and/or DataResource.mimeTypeId to identify
> the format of the blob.  Hence deprecating
> VideoDataResource,AudioDataResource,OtherDataResource.
>
> Any insight/comment is appreciated.
>
> Thanks,
> Wai

Cheers,
Bilgin

>
>
> --
> View this message in context: http://ofbiz.135035.n4.nabble.com/ImageDataResource-VideoDataResource-AudioDataResource-OtherDataResource-tp4354343p4373608.html
> Sent from the OFBiz - User mailing list archive at Nabble.com.
Wai
Reply | Threaded
Open this post in threaded view
|

Re: ImageDataResource, VideoDataResource, AudioDataResource, OtherDataResource

Wai
I agree that it's not much trouble to do the extra work of deleting an entry from one table and creating another in another table.  The point was that it's an extra step that was not required.  Hence simplifying the management process.  Even querying the database related to these separated tables become more complicated then it needs to be (ie. query all contents for a particular party/category/etc).

Unfortunately, I am not familiar with database tuning as it related to separate blob types so I cannot comment on it.

My proposal was to all the experienced ofbiz developers.  If no one can justify an advantage of having separate ImageDataResource, VideoDataResource, AudioDataResource, OtherDataResource.  Perhaps it would be better to only use ImageDataResource to store binary file uploads and deprecate all the others.

Thanks,
Wai