On 21 September 2012 11:24, Kevin Meyer - KMZ <[email protected]> wrote:

> > >
> > I must be missing something.  In:
> >
> > @Blob(mimeType="application/pdf")
> > public byte[] getCurriculumVitae() { ... }
> > public void setCurriculumVitae(byte[] cv) { ... }
> >
> > we have the mime type there.  What other info is it that we need?
>
> What Giedrius was saying, and which I agree with, is that the field (CV,
> in this case) does not *have* to be of a single document type.
>
> What if CVs are also submitted as Word docx and Open Office odts?
>
> This is a valid use-case.
>
>
Ah, I get it.

In which case, sounds like we ought to also define a value type for this.
 NO MVC uses something called FileAttachment, but I prefer "Blob":

public class Blob {
    public byte[] Content {get;set;}
    public string MediaType {get; set;}
}

But it'd be nice to also support @Blob as well; I think the requirement to
support multiple media types will be rare.  And, in the short-term, one
could do without this Blob value type; the lo-tech workaround would simply
be to have multiple properties in the object, one for each media type to be
stored.

~~~~~~~


>
>
>
> There is another question waiting in the wings: How would we handle
> this if you don't want to store the document byte stream as a blob in
> the database, but leave it on the file system?
> In the SQL-OS and I could just write a valuemapper that knows to
> fetch the actual byte stream via the filename (which would be stored in
> the database).. this uses the existing object store API. Is there another
> solution?
>
>
Perhaps the @Blob annotation and Blob value type could have an optional
attribute indicating the URI of the content?

The support for this Blob.Uri would be specific to each objectstore, but
(probably) transparent to the viewer.

Dan


> Regards,
> Kevin
>
>
>

Reply via email to