Deleting no images files from Java SDK

Comments

10 comments

  • Avatar
    Aleksandar Kostadinov

    Hi Alberto,

    Let me go ahead and share more details about the points you've highlighted:

    In Cloudinary, an asset is identified by not only the public_id on its own, but only when that public_id is in combination with the 'resource_type' (e.g, image, video, raw) and 'type' (upload, private, authenticated etc). You can have an image and a video both with the same exact public_id but they will be considered different assets because the resource_type is different.

    In light of this, what we recommend is every asset you upload you would store in your database not only the public_id but also the resource_type and type parameters as returned in the Upload API response. That way, you can perform any actions on the assets via the API as you will have those parameters ready. If you are not yet storing the resource_type and type on your side then we recommend using the Get Resources method of the Admin API to list all existing resources in your cloud, go through each one, grab the resource_type and type from the response and store those on your side as a one-off script. From then on, the code you're using should take those parameters from the Cloudinary upload API response and store them on your side for every file you upload to Cloudinary. Then you'll be able to call the API to delete or perform any other action on the files you have in Cloudinary because you'll have the public_id, resource_type and type of each and can pass them in the relevant API calls - like destroy().
     
    To answer your question, documents, such as Word, Excel, Text files, CSV etc are all classified as 'raw' assets and that will be the resource_type, therefore, to delete them you will need to pass resource_type => "raw" in your destroy() call. Otherwise, the value will default to "image" and hence we won't be able to find such an asset in your cloud.

    CR2 images are supported and will be interpreted as "image" resource_type. NEF files are not currently supported to be uploaded as "image" resource_type but you can upload them and they will be stored with resource_type "raw".

    In regards to the file size limits - those are dependent on the Cloudinary plan you're on and you'll be able to see those limits by going to the Settings -> Account tab -> on the right there will be a section called "Usage Limits" which will contain filesize limits too.

    The SDKs do not impose any limits themselves and the file size limits are validated on the Cloudinary backend side once we receive the file.

    0
    Comment actions Permalink
  • Avatar
    CloudAccount WARDA

    Hi Aleksandar,

    thanks for the reply, I'm trying to delete a pdf file while providing row as you indicated but it's not working.

    I uploaded the file using "raw" as you indicated and in the delete I'm passing:

    {resource_type=raw, invalidate=true}

     

    Furthemore I would like to have the list of mime type to pass in the case of not multimedia or documents file. For example .zip, and stuff like that. What should I provide?

    Thanks for the help.

     

    Best regards,

    Alberto

    0
    Comment actions Permalink
  • Avatar
    Aleksandar Kostadinov

    Hi Alberto,

    Thanks for your response.

    May I please ask you to share the full code snippet you are using to delete, including all parameters you are passing and the example public_id from your account that you are trying to delete? Based on that, we can see why the code is not working for you.

    In regards to your question - the possible resource_types you will need to use are "image", "video" or "raw". The one you need to use depends on how you've uploaded the asset. We return the resource_type for every file you upload and that should be stored in the database on your side alongside the 'public_id' and 'type' that is also returned in the API response for every file you upload.

    If you're uploading via the UI or passing "resource_type": "auto" in your code when uploading then we will default to automatically assigning the resource_type on our side based on the content of the file you are uploading. For example, if you upload an image, then we will use "image" as the resource_type. And if you upload a video or audio file then the resource_type will be "video". For a ZIP file, we will set resource_type to "raw". Apart from using "auto" resoucre_type when uploading and letting us figure out the right resource_type to use, you can upload assets by specifying the exact resource_type yourself (of course, that needs to match the file you're uploading and you cannot set resource_type:"image" on a CSV file for instance), as well as you can choose to upload image or video files as "raw" by passing resource_type: raw in your upload. Please see the following section in the documentation for more information on resource_type:
    https://cloudinary.com/documentation/upload_images#asset_types

    Looking forward to your updates.

    0
    Comment actions Permalink
  • Avatar
    CloudAccount WARDA

    Hi Aleksandar,

    thank for your response. When uploading we're always specifying the "resource_type" explicitly.

    Here the snipped that we're using (it's written in Scala but should be easy to understand):

    override def delete(fileName: String, fileType: FileType, fileTypeValue: String): ZIO[Blocking, Throwable, Unit] = {
    val options = ObjectUtils.asMap("invalidate",
    Boolean.box(true),
    "resource_type",
    getCloudinaryResourceType(fileType, fileTypeValue),
    "type",
    "upload"
    )
    for {
    _ <- ZIO.effect(logger.debug(s"CDNClient - START"))
    fileWithoutExtension <- ZIO.effect(removeExtension(fileName))
    _ <- ZIO.effect(logger.debug(s"CDNClient - fileWithoutExtension: $fileWithoutExtension"))
    responseOk: Option[(Any, Any)] <- ZIO.effect {
    import scala.collection.JavaConverters._
    val result =
    client.uploader().destroy(fileName, options).asScala

    result.find {
    case (`Result`, `Ok`) => true
    case _ =>
    logger.warn(s"Unexpected response from Cloudinary: ${result.mkString(", ")}")
    false
    }
    }
    _ <- ZIO.effect(logger.debug(s"CDNClient - responseOk: $responseOk"))
    _ <- ZIO.getOrFailWith(
    new Exception(
    s"Something went wrong while deleting $fileWithoutExtension from ${tenant.value}'s Cloudinary.'"
    )
    )(responseOk)
    } yield ()
    }

    For example one public id that we're getting the issue is the 

    it/doc

    that's a pdf file, using "raw" as "resource_type".

    If it can help, this is the link to the resource: https://cloudinary.com/console/c-703180ad2897a56d5db0c08e2f6c6f/media_library/folders/c03ac854be09762b2aa14090816a2e5f2f/asset/9b4238bb6df147752cd3beab949776a3/manage

     

    Thanks for the help.

     

    Best regards.

     

    Alberto

    0
    Comment actions Permalink
  • Avatar
    Warda Support

    Is it possibile to arrange a meeting to discuss about this topic?

    Best regards,

     

    Alberto

    0
    Comment actions Permalink
  • Avatar
    Aleksandar Kostadinov

    Hi Alberto,

    I've checked our logs over the past few days and I can see the requests to delete a public_id "it/doc" however those did not work because no public_id with that value existed in your cloud. The one that did exist was "it/doc.pdf" and also "it/doc.txt" which we also received a destroy() request for and those were deleted as expected. If you are passing the public_id for raw files without the extension then that would explain why the file cannot be found and hence deleted.

    Note that when you are uploading raw files, the public_id will be the filename (+any folders) as well as the extension itself. This is unlike images/video resource_types where only the filename (+any folders) are part of the public_id but not the extension.

    Do you have an existing asset (public_id) in your cloud that you are trying to delete that is not working given the above details?

    If you'd like to raise a direct ticket with us you could do so via - https://support.cloudinary.com/hc/en-us/requests/new - and if you're still facing issues we can organise a call if needed.

    0
    Comment actions Permalink
  • Avatar
    CloudAccount WARDA

    Hi Aleksander, after proving the file extension in the public id for the asset destroy call I can see that basically is working and deleting the file from the Cloudinary directory.

     

    I get only an issue that the file link seems to remain active, for example this link here:

    https://res.cloudinary.com/test-seecommerce/raw/upload/v1652444349/dev/digitalassets/original/d83dca2a-187a-453e-97d1-7f26114ef2cc.docx

    It is still enabled while the file doesn't exists anymore in the directory. I'm passing "invalidate" with true in the options of the destroy call.

    What is wrong? For the image and video is working all correctly.

     

    Best regards,

     

    Alberto

     

    0
    Comment actions Permalink
  • Avatar
    Aleksandar Kostadinov

    Hi Alberto,

    Great to hear the deletion now works after making those changes.

    In regards to the invalidation - I checked our logs and I see that indeed you passed the invalidate parameter and I can confirm that an invalidation request was sent to the CDNs.

    For me, that URL returns 404 when I access it, but if you first clear your local browser cache and request it again, do you get a cached response and can still access the file? If so, please clear your browser cache again, request the file and export a HAR file that will contain the full request/response headers and share that with us so that we can look into this further.

    0
    Comment actions Permalink
  • Avatar
    CloudAccount WARDA

    Hi Aleksandar,

    I generate an other link for a different file: https://res.cloudinary.com/test-seecommerce/raw/upload/v1652713244/dev/digitalassets/original/4d614164-5130-4a6b-8a00-8fb18f42f96e.docx 

    Here the requested file as link for the HAR file?  
    https://res.cloudinary.com/test-seecommerce/raw/upload/v1652714296/test_qckr6k.har

     

    Best regards,

    Alberto

    0
    Comment actions Permalink
  • Avatar
    Aleksandar Kostadinov

    Hi Alberto,

    Thanks for sharing the HAR file. Looking into it, I see that the response you received to the request for the above document was coming from your browser's cache and not the CDN. Please see the screenshot attached which is showing the request from the HAR file.

    May I please ask you to test that but after deleting the file, please clear your local browser cache or request the document from an incognito window of your current browser or in a new browser entirely to avoid cached responses.

    0
    Comment actions Permalink

Please sign in to leave a comment.