-
Notifications
You must be signed in to change notification settings - Fork 1
Storage Actions
This action converts (without touching the original files) all BinaryFile objects to be stored in the database. While it is doing that it also replaces the content with placeholder data. Again, without modifying the original production files.
Images get replaced with properly sized placeholder images. Documents get replaced with either placeholder documents if a known file type, otherwise an empty file.
You have various Storage Providers available to you in Rock. Some store in the database, some store the files on disk, some store them in the cloud. This action moves all those "non-database" stored files into the SQL database. So why, why why would we ever bloat the database by moving everything into the database? Well, a couple reasons.
- You are moving to a development server using the Rockit SDK and thus may not have all the on-disk files, so some things may not work correctly.
- You are moving to a sandbox or development server and don't want to risk accidentally deleting any cloud stored files.
Item 2 is especially important to note. Consider this situation, you have all your person profile images stored in Cloudinary or some other cloud provider. Your sandbox is pulling the images down and displaying them since it has access to all those files. Great, right? Except, to test something you upload a dummy image to your profile. Everything works, great. Not so much. You just erased the original image from the cloud, so your production instance can no longer get that image.
Basically, this allows you to create a self-contained instance of Rock (in terms of the Binary Files) so you don't have to worry about corrupting production data. Also take note that there is a System Settings action that lets you disable/reset storage providers. This is also helpful just to be sure nothing got missed.
As the name implies, this action simply replaces any database-stored images with empty images. Specifically, they are replaced with 1x1 pixel image. This is good for space reduction, but is primarily more of a data scrubbing feature. You may not want all your actual images on the sandbox or development machines.
A file is considered an image if it ends with jpg, jpeg or png.
As the name implies, this action simply replaces any database-stored images with properly sized images. Specifically, a white image is generated to match the original dimensions and black text of the resolution is drawn onto the image. This allows your images to still be properly sized, but no longer contain the orginal content. This is good for space reduction, but is primarily more of a data scrubbing feature. You may not want all your actual images on the sandbox or development machines.
A file is considered an image if it ends with jpg, jpeg or png.
Like the image version of this action, any "non-image" file is replaced with an empty placeholder. Specifically, a 0-byte file takes it's place. This is good for space reduction, but is primarily more of a data scrubbing feature. You may not want all your actual files (word docs, signed documents, etc.) on the sandbox or development machines.
A file is considered a non-image if it does not end with jpg, jpeg or png.
Like the image version of this action, any "non-image" file is replaced with a properly sized placeholder. Specifically, a file is generated of null bytes that takes up the same space as the original. This is primarily more of a data scrubbing feature. You may not want all your actual files (word docs, signed documents, etc.) on the sandbox or development machines.
A file is considered a non-image if it does not end with jpg, jpeg or png.