On 4/24/06, Nick Warner <[EMAIL PROTECTED]> 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.


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.



nrdo-list mailing list

Reply via email to