Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    Update binary fields server-side

    I have a datasource containing 2 binary (blob) fields. I use DMI to populate both of them server-side (see http://forums.smartclient.com/showthread.php?p=70842 for background.)

    One DMI issues an add/update request (containing blob1) to this datasource via DSRequest.execute. The other DMI intercepts that request and tries to add blob2 to the current request.

    I use the same bit of code (in DMI 2) for both add and update operations

    Code:
    ...
    byte[] decoded = Base64.decodeBase64(someString);
    InputStream someAttachment = new ByteArrayInputStream(decoded); 
    
    request.getValues().put("SOME_ATTACHMENT", someAttachment);
    request.getValues().put("SOME_ATTACHMENT_FILENAME", someFilename);
    
    //and so on
    The add operation seems to work, but the update operation does not. SOME_ATTACHMENT is always null. I can see in the log that for some reason, everything makes it into the values map except SOME_ATTACHMENT:

    Code:
    === 2011-08-15 15:56:20,768 [0-10] INFO  SQLDataSource - [builtinApplication.null] Performing update operation with
    	criteria: {ATTACHMENT_ID:"29"}	values: {SOME_ATTACHMENT_FILENAME:"MyFile.swf"}
    Is there some problem with the way I'm approaching this, or is this some very strange bug?
    Last edited by bbruyn; 15 Aug 2011, 15:40.

    #2
    We see a bug affecting field order in the query for update queries with multiple binary fields. It isn't immediately apparent how this could cause your database columns to be set to null, but it is definitely an error that would manifest as binary fields working OK in add operations but failing (perhaps sporadically) in update operations. Please try this again with tomorrow's nightly build and let us know if the problem is fixed.

    Comment


      #3
      I'll do that. Just for clarity, the build you're referring to will be marked 2011-08-16? (btw, the nightly builds don't look so nightly anymore - the last one is marked 2011-08-13)

      Comment


        #4
        Think of them as overnight builds. The folder you're looking at is for a 2.5.1 bug fix-only release, so there are not changes everyday.

        Comment


          #5
          Just to close the loop, it looks like the 8/16 build took care of this.

          Comment

          Working...
          X