Проблема хранилища данных загадочного движка приложений (ListProperty)

Question

Итак, у меня есть один и тот же код Python локально и в облаке Gae.

когда я сохраняю сущность локально, поле ListProperty установленного типа элемента datetime.datetime выглядит так в средстве просмотра хранилища данных:

2009-01-01 00:00:00,2010-03-10 00:00:00

когда я храню то же самое в облаке, средство просмотра отображает:

[datetime.datetime(2009, 1, 1, 0, 0), datetime.datetime(2010, 3, 9, 0, 0)]

почему разные представления?

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

Кто-нибудь придумает причину, почему это происходит, и решение этой проблемы?

ОБНОВЛЕНИЕ: мой запрос выглядит следующим образом (с использованием фильтров):

from x import y
from datetime import datetime
from google.appengine.ext import db

q = y.EntityType.all().filter('displayDateRange <=',datetime.now()).filter('displayDateRange >=',datetime.now())

usersResult = q.fetch(100)
print `len(usersResult)`

результат должен быть 1, вместо этого это 0.

На самом деле проблема заключается только в ListProperty с указанным значением datetime.datetime - запросы к StringListProperty работают в облаке так, как и ожидалось.

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

2009-01-01 00:00:00,2010-03-09 00:00:00
[datetime.datetime(2009, 1, 1, 0, 0), datetime.datetime(2010, 3, 9, 0, 0)]

на локальный и облачный соответственно.

Есть идеи?

Дальнейшее обновление

Заменен datetime.now() жестко закодированным datetime obj - пример фильтра теперь выглядит так:

y.EntityType.all().filter('displayDateRange <=',datetime(2009,11,24)).filter('displayDateRange >=',datetime(2009,11,24))

Обратите внимание, с указанным диапазоном DatePro ListProperty от 1.1.2009 до 3.9.2010 это должно вернуть вышеупомянутую сущность - я попробовал этот идентичный фильтр на сервере localhost dev, и он сделал это. Облако, с другим представлением DatePro.Datetime ListProperty, не имеет.

Обратите внимание, что это взято из текущей лучшей практики для фильтрации по диапазону дат

Есть идеи, что может быть не так?

Answer 1

Ладно, короткая история: теперь она классифицируется как ошибка в версии сервера приложений для движка приложений и больше не поддерживается в хранилище данных рабочего облака.

Заполните дальнейшее объяснение в блоге, проверьте пункт 3.

Answer 2

Проблема, которую вы видите, это явно преобразование в строку (вызов __str__ или же __unicode__) в локальном случае, в то время как представление (repr) ваших данных отображается в облаке. Но эта разница в распечатке результатов не должна быть причиной вашего неудачного запроса в облаке.

Какой ваш точный запрос?

ОБНОВЛЕНИЕ после знания запроса:

Я не очень понимаю, почему вы используете эти условия фильтра:

.filter('displayDateRange <=',datetime.now()).filter('displayDateRange >=',datetime.now())

Есть две проблемы с этим:

• Ты звонишь datetime.now() дважды, что может дать вам разные результаты, что приведет к пустому набору результатов. Это особенно верно для загруженного сервера с несколькими активными потоками / процессами исполнения одновременно.

• То, что вы, возможно, намеревались сделать с вышеуказанной парой фильтров, это проверка на равенство. Но это не сработает, если точность экземпляра datetime возвращается datetime.now() и точность даты и времени, хранящихся в базе данных, отличается. Не следует проверять равенство в случае чисел с плавающей запятой и значений времени с точностью до секунды.

Чего вы хотите достичь с такой парой условий фильтрации?