Сюрпризы sqlite CURRENT_TIMESTAMP

December 13th, 2008 Begemot Posted in Не wxWidgets

Думаете достаточно просто определить стобец как

created TIMESTAMP not null default CURRENT_TIMESTAMP,

и забыть про него. В смысле не задавать значения этого поля при вставке, мол sqlite сама туда добавит текущее время? Напрасно 🙂

SQLite действительно сама занесет в него текущее время при вставке строки, но это будет время в UTC, без учета вашего смещения. В таком случае читать его надо как

SELECT datetime(created, 'localtime') FROM my_table; 

вместо обычного

SELECT created FROM my_table;

Но я думаю что лучше сразу правильно писать в дб, указывая значения для этого столбца как datetime(‘now’, ‘localtime’). В коде использованием SqliteDatabaseLayer, это будет выглядеть примерно так

PreparedStatement* pStatement = db->PrepareStatement(wxT(“INSERT INTO log (created, title) VALUES (datetime(‘now’, ‘localtime’), ?);”));

Больше про функции работы с датой в sqlite.

 

 


Если пост полезен для вас вы можете подписаться на RSS или мы можем доставлять вам новые посты прямо в ваш почтовый ящик.

Related:

Posted in Не wxWidgets | Tags:

8 Responses to “Сюрпризы sqlite CURRENT_TIMESTAMP”

  1. Не, лучше влепливать в UTC, так ты точно будешь уверен что когда ты на своей тачке поменяешь часовой пояс, то время в базе не будет конфликтовать. А то, допустим, летишь ті в самотете из Москвы, запостил чото в базу в 9.00 утра, пересек часовой пояс, локальное время у тебя 8.05, а запостил ты данные в 9, получается что данные запостились в будущем. А так при изменении часового пояса в системе у теб ябудет нужное время всегда отображаться.

  2. Идиологически оно наверное так и есть, но имхо немного натянутый пример. во-первых не частый, во-вторых у меня конфликтов времени быть не может:) так что пофигу.

    И так получается мы один раз конвертим время, когда суем в бд, а если хранить в UTC придется конвертировать при каждой выборке…

  3. Николай, расскажи, пожалуйста, почему ты выбрал SqliteDatabaseLayer, а не wxSQLite3.

  4. Черт его знает… могу точно сказать что серьозных сравнений не проводил. Но кажется мне есть две причины.

    Первая, я в голове держу мысль про то, что одному из моих будущих глобальных проектов возможно понадобится сетевая бд, по все видимости FireBird, то с прицелом на это SqliteDatabaseLayer подходит больше.

    Вторая, мне в то время когда я думал что взять, T-Rex дал почитать свою статью “Организуем доступ к базам данных SQLite при разработке кросс-платформенных приложений на C++/wxWidgets” http://wxwidgets.info/wx_accessing_sqlite

  5. Почувствовал ли ты какие-нибудь серьезные ограничения обертки SqliteDatabaseLayer, которых бы, скорее всего, не было, если бы она была заточена только под одну конкретную RDBMS?

  6. какие серъёзные вопросы задаешь, однако:) большой проект планируется?

    Нет не почувствовал, но у меня требования маленькие – не выходящие за рамки тривиальных операций… так что ничего особо заточенного мне не надо.
    Да и потом там разные классы для разных движков, то есть возможно что она и не вводит серъозных ограничений ради строгой типизации интерфейса:)

  7. Да нет, я просто перестраховщик 🙂 Перед принятием решения что использовать, стараюсь взвестить все “за” и “против”.

    Я планирую переписывать свой тренажер Vocabilis на wxWidgets, а у меня там исползьуется SQLite (в новой версии, которая выйдет со дня на день). Отсюда и интерес к оберткам для баз данных.

    Спасибо за ссылку.

  8. о, я свой vteacher тоже планирую на вх переписать 🙂