2015-12-29 2 views
1

Приложение Engine Dev сервера documentation говорит следующее:Почему App Engine возвращает неправильный идентификатор приложения?

Сервер разработки имитирует производство App Engine службы. Один из способов, которым это делается, - добавить строку (dev~) к переменной окружения APPLICATION_ID. Google рекомендует всегда получать идентификатор приложения с помощью get_application_id


В моем приложении я использую различные ресурсы на местном уровне, чем я на производстве. Таким образом, я следующий, когда я запуск экземпляра App Engine:

import logging 

from google.appengine.api.app_identity import app_identity 
# ... 
# other imports 
# ... 

DEV_IDENTIFIER = 'dev~' 
application_id = app_identity.get_application_id() 
is_development = DEV_IDENTIFIER in application_id 

logging.info("The application ID is '%s'") 
if is_development: 
    logging.warning("Using development configuration") 

    # ... 
    # set up application for development 
    # ... 

# ... 

Тем не менее, когда я начинаю свой локальный сервер Dev с помощью командной строки с dev_appserver.py app.yaml, я получаю следующий вывод в моей консоли:

INFO: The application ID is 'development-application' 
WARNING: Using development configuration 

Очевидно, что идентификатор dev~, согласно которому требования к документации будут препринтами к моему идентификатору приложения, отсутствует. Я также попытался использовать пользовательский интерфейс Launcher App Engine, чтобы убедиться, что это что-то изменило, но это не так.

Обратите внимание, что «разработка-приложение» - это имя моего фактического приложения, но я ожидал, что это «dev ~ development-application».

ответ

6

Google рекомендует всегда получать идентификатор приложения с помощью get_application_id

Но вот если ты заботишься о идентификатор приложения - вы не так: вы заботитесь о раздела. Проверьте источник - он опубликован в https://code.google.com/p/googleappengine/source/browse/trunk/python/google/appengine/api/app_identity/app_identity.py.

get_app_identity использует os.getenv('APPLICATION_ID') затем передает, что во внутренней функции _ParseFullAppId - которая разделяет его на _PARTITION_SEPARATOR = '~' (таким образом удаляя снова dev~ префикс, который dev_appserver.py предваряется переменной среды). Это возвращается как «раздел» в get_app_identity (который игнорирует его, только возвращает идентификатор приложения в строгом смысле слова).

К сожалению, нет никакого архивированного способа получить только раздел (на самом деле все, о чем вы заботитесь).

Я бы рекомендовал, чтобы отличить ли вы локально или «на производстве» (то есть на серверах Google на appspot.com), чтобы получать доступ к различным ресурсам в каждом случае, вы черпаете вдохновение из-за пути Собственный пример Google делает это - в частности, проверьте пример app.py на https://cloud.google.com/appengine/docs/python/cloud-sql/#Python_Using_a_local_MySQL_instance_during_development.

В этом примере необходимо получить доступ к экземпляру Cloud SQL, если вы работаете в процессе производства, но локальный экземпляр MySQL, если вы работаете локально. Но это вторично - давайте сосредоточимся на этом, как показывает собственный пример Google, что это такое? Соответствующий код ...:

if (os.getenv('SERVER_SOFTWARE') and 
     os.getenv('SERVER_SOFTWARE').startswith('Google App Engine/')): 
     ...snipped: what to do if you're in production!... 
    else: 
     ...snipped: what to do if you're in the local server!... 

Итак, это тест, который я рекомендую вам использовать.

Ну, как гуру Python, я на самом деле слегка смущен, что мои коллеги используют этот слегка уступающий код Python (с двумя вызовами os.getenv) - меня, я бы закодировал его следующим образом:

in_prod = os.getenv('SERVER_SOFTWARE', '').startswith('Google App Engine/') 
if in_prod: 
    ...whatever you want to do if we're in production... 
else: 
    ...whatever you want to do if we're in the local server... 

, но это точно такой же семантика, только выраженные в более элегантной Python (используя второй необязательный аргумент os.getenv указать значение по умолчанию).

Я буду пытаться получить это небольшое улучшение Python в этот пример и также разместить его на странице дока вы используете (там нет причин никто просто не нуждаясь, чтобы узнать, если их приложение запущенно в проде или локально, должны были когда-либо смотреть на документы о применении Cloud SQL - поэтому, - это документация с нашей стороны, и, извинитесь). Но, пока я работаю над улучшением наших документов, я надеюсь, что этого SO-ответа достаточно, чтобы вы могли действовать уверенно.

+0

Есть ли версия документации, которая напрямую связана с обсуждаемым источником? Я обнаружил, что документы, на которые я смотрел, отличные, когда мне нужно понять концепцию, но когда мне нужно сделать что-то более сложное, трудно отследить источник. – nmagerko

+2

Все источники SDK можно просмотреть в Интернете по адресу https://code.google.com/p/googleappengine/source/browse/#svn%2Ftrunk%2Fpython, или вы можете загрузить их для просмотра на локальной машине по адресу https: //code.google.com/p/googleappengine/source/checkout и многими другими способами. –

2

Эта документация кажется неправильной, когда я запускаю команды локально, она просто выплевывает имя из app.yaml.

Это сказанное, мы используем

import os 
os.getenv('SERVER_SOFTWARE', '').startswith('Dev') 

, чтобы проверить, если это DEV сервер приложений.

+0

только что запустил 'os.getenv (" APPLICATION_ID "))' и он вернул версию приложения с добавленным 'dev ~', так что это интересно. – miah

+0

Я думаю, что они записали его назад. Как они есть, 'os.getenv (« APPLICATION_ID »)) не гарантированно дает надлежащий идентификатор приложения для конкретной среды, но подход, который я использовал выше, является. – nmagerko

+1

@nmagerko, точка, идентификатор приложения * NOT * для среды - это всегда строка в вашем app.yaml; префикс, такой как 'dev ~', называется «разделом» и не является частью идентификатора приложения. Я согласен, что документация путается по этим вопросам, и я работаю над ее улучшением в соответствии с моим ответом, который вы любезно приняли. –

Смежные вопросы