Помещаются ли задания в очереди задач в Google App Engine автоматически в серверную часть по умолчанию или они планируются в серверной версии для вызывающего их кода?
Допустим, у меня есть два бэкенда: один называется «тестовый», а другой — «производственный», где «производственный» — это моя версия по умолчанию.
В каждом из них у меня есть файл, упрощенный следующим образом:
from google.appengine.api import taskqueue
import webapp2
class QueueScheduler(webapp2.RequestHandler):
def get(self): #in real life, post, but this makes for an easier example
taskqueue.add('path/to/myTask')
app = webapp2.WSGIApplication(('/myScheduler',QueueScheduler))
Когда я звоню test.myApp.appspot.com/myScheduler, буду ли я создавать задачу, указывающую на test.myApp.appspot.com/path/to/myTask, или буду создавать задачу на myApp.appspot.com/path/to/myTask (т.е. production.myApp.appspot.com/path/to/myTask)
Есть ли способ контролировать это из кода? Допустим, у меня есть третий бэкэнд, который называется «очереди». Могу ли я каким-то образом изменить приведенный выше код, чтобы вызовы test.myAppp.appspot.com/myScheduler, production.myApp.appspot.com/myScheduler и queues.myApp.appspot.com/myScheduler генерировали задачу для вызова кода, полученного путем перехода к queues.myApp.appspot.com/path/to/myTask, сохраняя при этом «производство» в качестве версии бэкэнда по умолчанию?
мета: Если это имеет значение, конкретная проблема, с которой я имею дело, заключается в том, что моя компания использует другую версию нашего кода для нашего мобильного приложения, чем мы используем для веб-приложения. Мы жестко кодируем номер версии в наших приложениях, чтобы приложения указывали на версию, которая была по умолчанию, когда мы выпустили обновление, чтобы мы могли делать обратно несовместимые версии. Также часто бывает так, что мы хотим обновить нашу обработку данных до того, как мы обновим интерфейс, который видят наши пользователи. Я ищу решение, которое позволит нам сделать это без необходимости убедиться, что мы не пересматриваем нашу обработку данных, пока мы частично закончили изменения в интерфейсе, или работаем с несколькими ветвями нашего кода одновременно. Мы хотели бы, чтобы вызовы как стандартной, так и устаревшей версии нашего приложения могли выполнять обработку своих данных в версии, которая еще не готова к работе с клиентом. Создание задач в cron.yaml и установка там версии решает проблему для всех данных, которые мы должны поддерживать в актуальном состоянии, но для некоторых вещей мы предпочли бы накладные расходы на разработку в нескольких ветках, чем проблему отсутствия сохранения. данные в режиме реального времени.
