Cassandra: проблемы с временным поиском

-1

Я храню эпоху (количество миллиметров) в C * db, но когда дело доходит до получения данных строки, я получаю данные в следующем формате.Cassandra: проблемы с временным поиском

starts: { 
low: 1753507485 
high: 330 
unsigned: false 
}

Моя структура таблицы выглядит следующим образом:

CREATE TABLE ks.cron_tasks(
    type varchar, 
    starts bigint, 
    chatid varchar, 
    status varchar, 
    result varchar, 
    PRIMARY KEY (type, starts) 
);

Я проверил, что данные вводятся в БД правильно, но при получении данных обратно я получаю low и high параметры.

Примечание: Мой tz - IST (GMT + 330 минут).

Мой ввод был «1419092715165» значение для стартов.

Теперь, как я могу получить это точное значение обратно.

источник

2014-12-20 guptakvgaurav

В качестве альтернативного решения этой проблемы я могу хранить запуск в форме двойного и работает очень хорошо. Но все же мне любопытно узнать, как данные Bigint разделяются в высоких и низких частях. – guptakvgaurav

Основываясь на ваших тегах, я предполагаю, что вы используете драйвер node.js. Этот драйвер использует класс long.js для представления 64-битных целых чисел (bigint - это 64-битное целое число).

https://www.npmjs.com/package/long

низкие и высокие представляет собой первый и второй 32 бита целого числа. Вы должны иметь возможность получить строковое представление целого числа, вызывая toString() на длинном объекте.

//string value of the integer representation 
var val = row.starts.toString();

Google Closure Long documentation.

источник

2014-12-21 02:49:57 nickmbailey

Cassandra: проблемы с временным поиском

ответ

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