Deleting no images files from Java SDK
Hi,
I'm doing an integration to use the Java Cloudinary SDK for upload and destroy files to Cloudinary.
I'm getting the following issues:
- Deleting a document file is not working, I see that there is the resource_type settings, which value should I put? for the video using "video" is working the destroy method. Instead for the document without the resource_type the sdk is returning all ok but no file is deleted.
- Support for generic files: how can i delete a file that is no image, video or document? Is it possibile and should i provide some resource_type in the destroy call?
- Does Cloudinary suppor RAW files (NEF, CR2 extension)? Because from the web portal I see that 10MB is the maximum allowed size and is too small for my use case. But from the SDK I'm not able to upload it. Is there some way to do that? and to delete also?
Best regards,
Alberto
-
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 -
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 -
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_typesLooking forward to your updates.
0 -
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 -
Is it possibile to arrange a meeting to discuss about this topic?
Best regards,Alberto
0 -
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 -
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:
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 -
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 -
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.harBest regards,
Alberto
0 -
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
Post is closed for comments.
Comments
10 comments