Значение IntegerField преобразуется в строку для некоторых чисел

Наличие класса сообщений Cloud Endpoints (ProtoRPC) с целочисленным полем, например.

TestMsg(messages.Message):
  int_field = messages.IntegerField(1)

и метод:

@endpoints.method(VoidMessage, TestMsg)
def test_int_field():
  return TestMsg(int_field=1234567890123)

На локальном сервере разработки ответ JSON правильно приводит к следующему результату:

{ int_field: 1234567890123 }

В то время как в производстве число по какой-то причине преобразуется в строку:

{ int_field: "1234567890123" }

Однако для меньших чисел целые числа, похоже, не преобразуются в строки.

Это ожидаемое поведение? Кто-нибудь может воспроизвести? (Если это имеет значение: я запускаю этот код в центрах обработки данных ЕС)


person alex    schedule 13.04.2013    source источник
comment
Конечные точки IIRC делают это, когда число больше MAX_INT.   -  person proppy    schedule 13.04.2013
comment
Также см. > stackoverflow.com/questions/8663298/   -  person proppy    schedule 13.04.2013
comment
Ах, это, безусловно, объяснило бы это (дело MAX_INT). Хотя я пробовал с Variant.UINT64 и другими вариантами, тот же результат. Другой вопрос SO о преобразовании bigints в Javascript - это другая история, я не зашел так далеко с числами :) Спасибо @proppy   -  person alex    schedule 13.04.2013
comment
Проблема в том, что это где-то в конечных точках (ProtoRPC этого не делает). На всякий случай я создал задачу: code.google.com/p. /googleappengine/issues/detail?id=9173   -  person alex    schedule 13.04.2013
comment
s/MAX_INT/максимальная интегральная точность с использованием двойного представления/, поскольку в других вопросах SO говорится, что JSON не может представлять все произвольные большие целые числа с использованием числового типа.   -  person proppy    schedule 13.04.2013
comment
Итак, я хотел использовать целые числа для временных меток в миллисекундах. Думаю, мне придется просто использовать формат строки ISO или что-то в этом роде (DateTimeField)   -  person alex    schedule 13.04.2013
comment
Клиентские библиотеки должны поступать правильно, когда получают большое поле ввода, закодированное в виде строки.   -  person proppy    schedule 13.04.2013
comment
Черт, жаль, что у меня не было времени реализовать что-то вроде Endpoints в Go. gorilla/rpc, кажется, движется в этом направлении.   -  person alex    schedule 13.04.2013
comment
@alex Кажется, твой комментарий сбылся :)   -  person bossylobster    schedule 16.05.2013
comment
@bossylobster :) да, я написал этот комментарий, но не мог избавиться от мысли в голове. Итак, через пару дней я начал экспериментировать и... ну, вы знаете, чем я закончил, хе-хе. Кстати, я не думаю, что зашел бы так далеко без вашей помощи, так что еще раз спасибо!   -  person alex    schedule 16.05.2013


Ответы (1)


Думаю, @proppy прав. Кроме того, в формате обнаружения четко указано, что

32-разрядное целое число со знаком (тип "целое число", формат int32). Он имеет минимальное значение -2 147 483 648 и максимальное значение 2 147 483 647 (включительно).

и

32-разрядное целое число без знака (тип "целое число", формат uint32). Он имеет минимальное значение 0 и максимальное значение 4 294 967 295 (включительно).

Все другие типы значений int/bigint/любые представлены как "строковые" типы с разными форматами. Дополнительная информация: https://developers.google.com/discovery/v1/type-format< /а>

Таким образом, число 1234567890123 на самом деле не может быть представлено в виде «целого числа». Просто сервер разработки не преобразует целые числа в строки автоматически (как это делает производственная инфраструктура), и я не осознавал, насколько большим было число при локальном тестировании.

Оказывается, команда Google уже работает над тем, чтобы сделать его согласованным: https://code.google.com/p/googleappengine/issues/detail?id=9173

person alex    schedule 14.04.2013
comment
Да. В protorpc добавлены некоторые изменения (google-protorpc-review.appspot.com/93001), чтобы гарантировать согласованность этого поведения. - person bossylobster; 16.05.2013