这是我们的简单用例:user2希望将user1的文档复制到应用程序中他或她自己的存储库中。应该简单吧?我们需要做的就是在blobstore中创建第二个相同的blob,并返回可以与user2关联的键。我们必须在这里丢失一些东西。 App Engine Blob存储区的主要功能似乎是处理从浏览器上传和下载到浏览器的Blob,而在服务器端启动的简单复制操作并非如此简单。
显而易见的解决方案似乎是在Java中使用实验文件api,但没有任何帮助。它可以正常工作,直到文件大小超过MB左右为止,然后失败,这在某种程度上是无法预料的。当我们只需要在存储层中进行复制时,将它们全部读取到服务器层中似乎也很愚蠢。此外,我们将试验性功能引入生产环境的可能性很小,尽管不为零。
有关我们环境的一些信息:该应用程序是用Java编写的,并且我们使用的是Blobstore,而不是云存储,并且目前已致力于使用它。我们是一个很小的部门团队,并且想证明应用程序引擎是一个很好的平台,但是这个让我们很沮丧。 S3使这一过程变得非常简单,我们是否在这里遗漏了一些真正愚蠢的东西?
最佳答案
我们最终放弃了用文件api制作blob的程序化副本,并按照Kalle在其注释中建议的引用进行引用的想法,并创建了一个新的外部参照实体,该实体存储有关副本和原始文档的信息。当删除图像或文件时,我们将检查xfef实体以获取引用,并删除指向该图像/文件的对象(即,如果删除的图像/文件是从另一个复制过来的,则创建)。如果根本找不到任何外部参照,则删除Blob本身。我们不喜欢留下孤立的Blob所带来的隐私/合规性,即使存储价格便宜,每个$$$都会有所帮助。可以这么说,我们也喜欢保持整洁的房子的想法。