Доступ к базовому объекту Google Cloud Storage из GAE createUploadUrl

Я пытаюсь сохранить загруженные фотографии пользователей в Google Cloud Storage, но у меня возникают проблемы с вызовом:

blobStoreService.createUploadUrl(...)

Мне нужно отслеживать, какой идентификатор пользователя связан с загруженным файлом. Если идентификатор пользователя равен 1234, мне нужно сохранить его как метаданные в файле облачного хранилища.

Я могу добавить метаданные при непосредственном создании файла облачного хранилища:

GSFileOptionsBuilder optionsBuilder = new GSFileOptionsBuilder()
    .setBucket("myBucket")
    .setKey(key) // path...
    .addUserMetadata("userId", "1234");

Но я действительно хочу использовать предоставленный GAE BlobStoreService.createUploadUrl(...), потому что он поддерживает файлы большего размера, чем может обработать приведенный выше код. Можно ли вообще указать метаданные с помощью createUploadUrl? Или даже возможно узнать, какой ключ / имя файла хранилища Google создан?


Обновить У меня уже есть blobKey из серввета обратного вызова загрузки. Однако я не могу найти способ добавить метаданные в файл Google Storage, связанный с этим blobKey. По крайней мере, локально он думает, что это запись BlobStore, а не файл GS.

    // get the key:
    Map<String, List<BlobKey>> blobKeysFromPost=BlobstoreServiceFactory.getBlobstoreService().getUploads(request);

    // pull out the blobKey generated from the recently submitted POST
    BlobKey blobKey = ... 

    // Now how do I access the cloud storage entry for this key?  I tried:
    AppEngineFile file = FileServiceFactory.getFileService().getBlobFile(blobKey);

    // But this file locally returns "blobstore":
    file.getFileSystem().getName(); // Should be GS.

person brariden    schedule 25.10.2012    source источник
comment
Если вы запускаете этот код на сервере разработки, файлы хранилища Google хранятся в хранилище больших двоичных объектов. Вы должны иметь возможность просмотреть объект BlobInfo для blobKey, чтобы увидеть имя файла. Невозможность добавить метаданные, вероятно, является ошибкой.   -  person Stuart Langley    schedule 26.10.2012


Ответы (2)


Я думаю, что это ошибка, из-за которой при загрузке файлов в Google Storage предоставляются BlobKeys, которые говорят, что они находятся в BlobStore. Не зная сгенерированного имени файла, мы не можем взаимодействовать с загруженным файлом в GS. Например, мы не можем добавить метаданные в файл, изменить ACL, удалить и т. д.

Я открыл эту проблему в трекере GAE: http://code.google.com/p/googleappengine/issues/detail?id=8337

person brariden    schedule 25.10.2012
comment
Я отмечаю это как правильный ответ, потому что кто-то еще подтвердил ошибку в системе отслеживания проблем GAE. Спасибо... - person brariden; 13.11.2012

Из документов:

Когда пользователь отправляет форму, POST обрабатывается API Blobstore, который создает большой двоичный объект. API также создает информационную запись для большого двоичного объекта и сохраняет запись в хранилище данных, и передает переписанный запрос вашему приложению по заданному пути в виде ключа большого двоичного объекта:

https://developers.google.com/appengine/docs/java/blobstore/overview#Uploading_a_Blob

Поэтому, как только он будет загружен, вы получите ключ большого двоичного объекта, который затем сможете сохранить и добавить метаданные. Я знаю только о Python, но, насколько мне известно, вы не можете добавлять метаданные такого рода в сущность хранилища больших двоичных объектов, вы должны отслеживать их самостоятельно.

person Paul Collingwood    schedule 25.10.2012
comment
предлагаю выложить свой код для обработчика в вопросе с форматированием, может кто что подметит. - person Paul Collingwood; 25.10.2012
comment
Спасибо, Пол С., я обновил вопрос, и он выглядит намного лучше. Извините, это первый вопрос, поэтому я просто разбираюсь с этим... - person brariden; 25.10.2012
comment
НП. И, насколько я знаю, вы не добавляете метаданные напрямую, вы сами сохраняете ключ и добавляете метаданные туда, где вы его храните. Если я все же правильно помню! - person Paul Collingwood; 25.10.2012