Хеш рассчитывается один раз при загрузке файла, независимо от того, будут им пользоваться или нет. Потом он только берется из хранилища данных. Я его использую потому, что он характеризует файл, в отличие от BlobKey.
Там есть и другие полезные свойства, которые можно использовать:
# Properties:
# content_type: Content type of blob.
# creation: Creation date of blob, when it was uploaded.
# filename: Filename user selected from their machine.
# size: Size of uncompressed blob.
# md5_hash: The md5 hash value of the uploaded blob.
Если принципиально использование id, то без этого, похоже, не обойтись. Однако, я делал приложения для хранения мелких файлов и брал за основу имя файла — возможности BlobInfo использовались более полно и получилась некоторая поддержка версий.
Пример выдачи файла с указанными именем и MD5:
class ServeFile(BlobstoreDownloadHandler): #webapp route: (r'/([a-hA-H0-9]{32})/.*', ServeFile),
def get(self, md5):
result = blobstore.BlobInfo.all().filter('md5_hash =', md5).get()
if not result: return self.error(404)
self.send_blob(result.key())
Пример выдачи последнего загруженного файла с указанным именем:
class ServeLatest(BlobstoreDownloadHandler): #webapp route: (r'/(.*)', ServeLatest),
def get(self, filename):
result = blobstore.BlobInfo.all().filter('filename =', filename).order('-creation').get()
if not result: return self.error(404)
self.send_blob(result.key())
Для работы второго примера в index.yaml необходимо прописать
В целом, BlobInfo во многом похож на обычный db.Model, и в исходниках есть неплохая документация к нему.
Для разработки под GAE хочу посоветовать PyCharm. Эта IDE поддерживает App Engine из коробки, существенно повышает скорость и удобство и позволяет удобно читать исходники SDK.
У меня такое ощущение, что мы пользуемся разными App Engine. Ни проблем с доступностью бесплатных приложений на HRDS, ни проседаний замечено не было. Запросы по 40-50мс — обычное дело. Конечно, пинг до Штатов великоват, но в веб-приложениях это не критично. Бесплатный GAE предоставляет сервис лучше чем большинство (если не все) отечественных платных хостингов. А встроенные инструменты разработчика позволяют экономить множество времени и сил при разработке и запуске приложения.
SLA Amazon EC2 несколько меньше — 99,95% в год. И это не гарантия того, что сервис будет работать бесперебойно. Если EC2 будет лежать больше 4 часов 23 минут, то можно получить обратно 10% от оплаты. У платных приложений App Engine SLA 99,95% в месяц. То есть 10% можно требовать уже после 22 минут отключки.
Подвох в том, что создать ящик со слабым паролем не дают, а сменить пароль на слабый — всегда пожалуйста. Немного удивился, когда увидел, что некоторые пользователи спокойно поменяли на такие, с какими ящики создать не удалось.
Пара десятков пользователей, и гугл становится заметно платным. А это дополнительные сложности при согласовании и дополнительная работа с бухгалтерией. Сейчас организовываю пластиковую карту для компании — это надо каждый день напоминать бухгалтерии, чтоб они напомнили банку выслать необходимые документы. Первая неделя прошла безрезультатно.
Подключить домен? Организовать песочницу? Отследить правильность DNS? Безопасность паролей?
Разве API может решить все проблемы? Это не серебряная пуля, особенно если сервис настолько не приспособлен.
От всех не набегаешься — остальные тоже люди и тоже делают ошибки. К тому же из конкурентов только Гугл, а у него пара десятков ящиков уже заметно платные. Перенос почты — лишь часть работ по смене хостера, и я бы предпочел вообще не заниматься этим. Но пришлось поработать и админом, и тестировщиком Яндекса.
Интереснее всего было бы посмотреть, как работает мозг, когда узнает знакомого на старой фотографии. Ведь с возрастом черты лица меняются довольно сильно.
App Engine теперь и время работы инстансов по-другому считает. Из всего времени жизни инстанса учитывается только время обработки запросов (с 15-минутным интервалом). Подогрев приложения по крону может стать сильно невыгодным.
Графики из тестового приложения:
По потреблению памяти видно, что инстанс жил почти 5 часов, в то время, как учтенное «платное» время составило 15 минут.
Функционально-ориентированный подход сильно ограничивает возможность использования своих декораторов. Если в webapp можно спокойно сохранить словарь с данными в self и сгенерировать страницу по шаблону в декораторе, то здесь такое не пройдет. Здесь есть ещё немного про сравнение схем.
Указание маршрутов в декораторе выглядит неплохо для маленького приложения, но в приложении побольше придется лазить по коду в поисках нужного обработчика (в то время, как в webapp его можно быстро найти, посмотрев в общий список). И о ленивом загрузчике в таком случае можно только мечтать — приложение на flask просто обязано быть маленьким.
Не знаю, как Вам, но мне наличие пары дополнительных функций такой ценой совсем не нужно.
Там есть и другие полезные свойства, которые можно использовать:
Пример выдачи файла с указанными именем и MD5:
Пример выдачи последнего загруженного файла с указанным именем:
Для работы второго примера в index.yaml необходимо прописать
В целом, BlobInfo во многом похож на обычный db.Model, и в исходниках есть неплохая документация к нему.
Для разработки под GAE хочу посоветовать PyCharm. Эта IDE поддерживает App Engine из коробки, существенно повышает скорость и удобство и позволяет удобно читать исходники SDK.
SLA Amazon EC2 несколько меньше — 99,95% в год. И это не гарантия того, что сервис будет работать бесперебойно. Если EC2 будет лежать больше 4 часов 23 минут, то можно получить обратно 10% от оплаты. У платных приложений App Engine SLA 99,95% в месяц. То есть 10% можно требовать уже после 22 минут отключки.
Есть еще почта для домена от Рамблера, но к ним соваться совсем не хочется.
А сейчас вообще ситуевина — один ящик ни в какую не желает переноситься. И в тех. поддержке не могут сказать в чем дело и просят еще подождать…
Разве API может решить все проблемы? Это не серебряная пуля, особенно если сервис настолько не приспособлен.
Активно работающих при этом может быть сколько угодно.
Графики из тестового приложения:
По потреблению памяти видно, что инстанс жил почти 5 часов, в то время, как учтенное «платное» время составило 15 минут.
Функционально-ориентированный подход сильно ограничивает возможность использования своих декораторов. Если в webapp можно спокойно сохранить словарь с данными в self и сгенерировать страницу по шаблону в декораторе, то здесь такое не пройдет. Здесь есть ещё немного про сравнение схем.
Указание маршрутов в декораторе выглядит неплохо для маленького приложения, но в приложении побольше придется лазить по коду в поисках нужного обработчика (в то время, как в webapp его можно быстро найти, посмотрев в общий список). И о ленивом загрузчике в таком случае можно только мечтать — приложение на flask просто обязано быть маленьким.
Не знаю, как Вам, но мне наличие пары дополнительных функций такой ценой совсем не нужно.