ibmi-brunch-learn

Announcement

Collapse
No announcement yet.

Storing Image

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Storing Image

    How can I store an image coming in from an API? What I really want to do is store the "base64 I think" code I think into a physical file. Then convert when I need to send the image. Or grab the image using our exit API coming in from our IOS app and store it to the IFS. Then I can move it around from there. Just not sure what direction to go.
    So basic problem is I have in incoming image coming from an API and need to store that file somewhere.

    Ideas? Thoughts?

  • #2
    Store it in whatever format you are going to need on those occasions when you need to send it out to the world. e.g. If to send it out to an iOS app you need to send it base64 encoded then store it that way. If on the other hand the app is going to get an image link that maps to the IFS then decode the base64 and store the result in the IFS.

    Basically minimize the number of times that you need to decode/encode.

    I see little point in storing the image date (in any form) in the database - but I would store the IFS reference there.

    Comment


    • #3
      I don't think it makes a lot of sense to store an image in a database file. Database files are more suitable for table type data, something an image isn't. STMFs are designed for storing streams of binary data so it makes far more sense to use these.
      You mentioned base64 encoding. is there a need to do that? This may have been your thoughts on storing it in a PF where you convert binary data to text but if it is stored as a STMF, I wouldn't have thought this necessary. It would obviously be more efficient to avoid encoding/decoding steps.

      Comment


      • jtaylor___
        jtaylor___ commented
        Editing a comment
        I find it convenient to store sometimes put stream files into BLOB columns in Db2. I prefer that to having a table row that links to an IFS file.

      • jtaylor___
        jtaylor___ commented
        Editing a comment
        I find it convenient to sometimes put stream files into BLOB columns in Db2. I prefer that to having a table row that links to an IFS file.

    • #4
      I see three alternatives presented in your message:
      1. Save the base64 encoded string (still encoded) into a CLOB column in a database table. (aka "physical file")
      2. Save the decoded image into a BLOB column in a database table.
      3. Save the decoded image into a stream file using the IFS.
      4. -- and of course -- you didn't ask about this, but you could also save the base64 encoded data into a stream file.


      I think what you're asking us to how to choose between these options, correct?

      Saving the decded data to an IFS stream file will be the most efficient in terms of disk space. It will also make it easiest to serve out using protocols like HTTP or FTP. This is the most common choice.

      Saving it to a database is popular when you expect the data to be retrieved as part of a database transaction. For example, if the image is associated with an HR record and the rest of the HR data is stored in a database table, then it makes sense to also store the image there. That way, everything can be retrieved with a single SQL statement, or written with a single statement, all backed up together, etc. If propagating data between systems (for example, for high-availability with a tool like MIMIX or performance with DB2 Mirror, etc) having them all together in the database is really useful, too.

      The disadvantage to the database is that if you need to access it via mapped drive, HTML page, FTP script, etc, it will require you to first run an SQL statement to extract it to the IFS, then you can get it, then you have to remove the temporary copy from the IFS. So a bit of extra work.

      As for storing it still base64 encoded vs. saving the decoded image... The advantage to base64 encoding is that it's plain text and transferring it between systems in a text-only transfer medium will not change its value. For example, it can be converted from ASCII/EBCDIC/UNICODE without hurting the data, it can be sent in text-only media such as E-mail, XML, or JSON without problems, etc. But, it does require more disk space, and before you can use the image as an image, you you have decode it.

      So I guess it all depends on how you plan to use the data. I think for most people storing it decoded is the best option because it's ready to use. If you need to transfer it or embed it into a document, you'd have to base64 encode it first, but this isn't usually a problem because you already have to go through a document creation process, so you just make it part of that process. E-mail software will typically do this automatically, so its actually easier to attach to an e-mail if its already decoded. But, if you're going to be constantly using it already encoded, and rarely need to decode it, then I could see the argument for storing it in encoded format, even though that uses more disk space, because it'd save a little bit of processing time.

      Does that help? Your question was pretty open-ended.

      Comment


      • #5
        So this gave me lots to think about. What I decided to do was send the image from the IOS app in base64. I can then decode it to the image.jpg on the IFS. This all works great. However, now I want to cpy that file to a network drive. So cpy it to a directory on the network. Is there any good way to do this? It will need to run in a CL program in batch as I have a listener for the calls to my endpoint API on the iseries.

        Thoughts?

        Comment


        • #6
          one other quick fun question. How do you create a Physical File with CLOB? I could store the data and convert when needed. It might be fun to play with code as well.

          Comment


          • #7
            Originally posted by CaptainRon View Post
            one other quick fun question. How do you create a Physical File with CLOB? I could store the data and convert when needed. It might be fun to play with code as well.
            CREATE TABLE SQL command.

            Comment

            Working...
            X