[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [nrdo-list] Sql image columns revisited
From: |
Stuart Ballard |
Subject: |
Re: [nrdo-list] Sql image columns revisited |
Date: |
Mon, 24 Apr 2006 11:28:25 -0400 |
On 4/24/06, Nick Warner <address@hidden> wrote:
>
>
> There was a question posed recently about image columns, and the answer was
> to use a string that is Base64-encoded. I'm currently storing scanned images
> in the database and would like to use nrdo to create the data-aware object.
> Based on that, do any concerns jump readily to mind?
I can't think of any. Base64-encoded binary data is just a string like
any other.
> In the meantime, I'm going to attempt to use the solution described above
> and see how well it works, but I want to change as little existing code as
> possible. I believe that I can insert the byte-array-to-Base64-string code
> between my custom scanning code and the data object so as not to cause a
> problem.
>
> Any other ideas?
As far as making the API friendly to use, the approach I think I
suggested in my last email was to name the column something slightly
different from what you want the property to be called, and then add a
public property using partial classes.
ie:
table foo {
fields {
...
string image_data_b64 text nullable readwrite [the image data];
...
};
}
public partial class MyNameSpace.Foo {
public byte[] ImageData {
get {return base64decode(ImageDataB64);}
set {ImageDataB64 = base64encode(value);}
}
}
where you supply the base64encode() and decode() functions.
Then when you *use* the Foo class, you could just pretend the
ImageData field was a real byte[] field even though it's
base64-encoding under the hood and storing in a different field.
HTH,
Stuart.
--
http://sab39.dev.netreach.com/