Ошибки при загрузке данных из Google App Engine с помощью Bulloader - PullRequest
Новая
       43

Ошибки при загрузке данных из Google App Engine с помощью Bulloader

3 голосов
/ 10 марта 2011

Я пытаюсь загрузить некоторые данные из хранилища данных, используя следующую Команда: 

appcfg.py download_data --config_file=bulkloader.yaml --application=myappname 
                        --kind=mykindname --filename=myappname_mykindname.csv
                        --url=http://myappname.appspot.com/_ah/remote_api

Когда у меня не было много данных в этом конкретном виде / таблице, я мог загрузить данные одним выстрелом - иногда сталкивается с следующая ошибка: 

.................................[ERROR   ] [Thread-11]
ExportProgressThread:
Traceback (most recent call last):
  File "C:\Program Files\Google\google_appengine\google\appengine\tools
\bulkload
er.py", line 1448, in run
    self.PerformWork()
  File "C:\Program Files\Google\google_appengine\google\appengine\tools
\bulkload
er.py", line 2216, in PerformWork
    item.key_end)
  File "C:\Program Files\Google\google_appengine\google\appengine\tools
\bulkload
er.py", line 2011, in StoreKeys
    (STATE_READ, unicode(kind), unicode(key_start), unicode(key_end)))
OperationalError: unable to open database file

Вот что я вижу в журнале сервера: 

Traceback (most recent call last):
  File "/base/python_runtime/python_lib/versions/1/google/appengine/
ext/remote_api/handler.py", line 277, in post
    response_data = self.ExecuteRequest(request)
  File "/base/python_runtime/python_lib/versions/1/google/appengine/
ext/remote_api/handler.py", line 308, in ExecuteRequest
    response_data)
  File "/base/python_runtime/python_lib/versions/1/google/appengine/
api/apiproxy_stub_map.py", line 86, in MakeSyncCall
    return stubmap.MakeSyncCall(service, call, request, response)
  File "/base/python_runtime/python_lib/versions/1/google/appengine/
api/apiproxy_stub_map.py", line 286, in MakeSyncCall
    rpc.CheckSuccess()
  File "/base/python_runtime/python_lib/versions/1/google/appengine/
api/apiproxy_rpc.py", line 126, in CheckSuccess
    raise self.exception
ApplicationError: ApplicationError: 4 no matching index found.

Когда появилась эта ошибка, я просто перезапустил бы загрузку и все такое будет хорошо работать.

В последнее время я замечаю, что по мере увеличения размера моего вида скачать инструмент не удается гораздо чаще. Например, с видом с ~ 3500 сущностей мне приходилось запускать по команде 5 раз - только последний из что удалось. Есть ли способ обойти эту ошибку? Раньше мой единственный беспокойство было, что я не смогу автоматизировать загрузку в сценарии, потому что случайных неудач - теперь я боюсь, что не смогу получить данные вообще.

Этот вопрос обсуждался ранее здесь но пост старый, и я не уверен, что делает предложенный флаг - следовательно, снова отправляю мой аналогичный запрос

Некоторые дополнительные детали. Как уже упоминалось здесь Я попытался предложить продолжить прерванную загрузку (в разделе Загрузка данных из App Engine ). Когда я возобновляю работу после прерывания, я не получаю ошибок, но количество загруженных строк меньше, чем количество объектов, которое показывает мне администратор хранилища данных. Это сообщение, которое я получаю: 

[INFO    ] Have 3220 entities, 3220 previously transferred
[INFO    ] 3220 entities (1003 bytes) transferred in 2.9 seconds

Администратор хранилища данных говорит мне, что этот конкретный вид имеет ~ 4300 сущностей. Почему остальные сущности не загружаются?

Спасибо!

1 Ответ

0 голосов
/ 18 марта 2011

Я собираюсь сделать совершенно необразованное предположение об этом, основываясь только на том факте, что я увидел слово «юникод» в первой ошибке; У меня была проблема, связанная с тем, что мои данные генерировались пользователем из Интернета. Пользователь вставил несколько символов Юникода, и вся куча вещей начала ломаться - возможно, по моей вине - так как я реализовал красивые функции repr и множество других вещей. Если вы можете, сделайте быстрое сканирование ваших данных с помощью утилиты консоли в вашем живом приложении, возможно (если это только записи 4k), попробуйте преобразовать все данные в строки ascii, чтобы найти те, которые не соответствуют.

И после этого я начал "дезинфицировать" пользовательский ввод (извините, но мое поле "публичного дескриптора" должно быть только для игроков!)

...