TBA

Сейчас работаю над тем, чтобы можно было квесты подгружать в бота динамически. Т.е. всё это время до этого квест писался в виде кода. Это было вполне удобно и читаемо, к примеру один из стандартных узлов квеста:

private void balcony(ChooseContext ctx) {
    messages(
            "Ваш взор быстро бежит по серым окнам многоэтажек.",
            "Котами тут даже и не пахнет.");
    poll("Легкий дождь начинает перерастать в ливень.")
            .choice("Вернуться в дом 🏙", this::closeWindow)
            .choice("Закрыть глаза 😌", this::closeEyes)
            .send();
}

В таком формате было удобно работать долгое время, но из минусов - необходимость перезагружать бота на каждое исправление. И это может быть прям неприятно, хочешь исправить опечатку, а не можешь, множество игроков проходит квест в данный момент, придётся ждать. Опять же надо быть всегда рядом с компьютером, и на ходу поправить\дополнить\запустить невозможно. Ну и многословность тоже не всегда удобна. Поэтому после некоторых размышлений, я решил разработать формат, который было бы удобно и читать, писать и поддерживать.

  balcony:
    text:
      - "Ваш взор быстро бежит по серым окнам многоэтажек."
      - "Котами тут даже и не пахнет."
      - "Легкий дождь начинает перерастать в ливень."
    choices:
      "Вернуться в дом 🏘": [ "close_window" ]
      "Закрыть глаза 😌": [ "close_eyes" ]

Это т же узел квеста но уже в формате конфигурации

Система подсчёта места чата в общем рейтинге всегда работала как-то подозрительно, хотя и была внимательно покрыта тестами.
И в очередной раз, обратив внимание на то что у чата, который поймал двух котов сообщение

Ваш счёт лучше чем у 92.4% чатов!

А у того, который поймал 4х

Ваш счёт лучше чем у 72.7% чатов!

Я решил докопаться до истины, развернул дамб БД локально и начал дебажить.

SELECT cue.chat.id, sum(cue.result)
FROM CatUserEvent cue
WHERE cue.date > :fromDate
  AND cue.catType != 0
GROUP BY cue.chat.id

Вот так выглядит SQL запросик, выглядит правильно и логично. Отсеиваем по типу баллы за картинки(шут знает, за что их дали) и группируем по чату.
Делаю выборку, залезаю в результаты и наблюдаю, что чат, который должен был получить 2 бала, имеет 8 😳
Смотрю, что ж там за события такие, что аж 8 набралось, и вижу результаты:

CLOSE
CAT1
CAT1

А теперь внимание, тип события хранится в енуме, который сохраняется через ordinal.

public enum CatRequestVote implements CallbackItem {
    NOT_CAT(0, "crv0", "Любопытный Кот сбегает от "),
    CAT1(1, "crv1", "Любопытный Кот убегает к "),
    CAT2(2, "crv2", "Два кота засчитано игроку "),
    CAT3(3, "crv3", "Целых три кота засчитано "),
    CAT4(4, "crv4", "Целых 4 кота засчитано "),
    LIKE_PHOTO(-1, "crvl", null),
    TIMEOUT(0, "crv0", "Любопытный Кот не дождался "),
    CLOSE(0, "crv0", null);
}

И как вы видите CLOSE находится на 8 месте и имеет индекс 7, т.е. 7+1+1=9. Удивление! Тайна раскрыта, правим запрос:

SELECT cue.chat.id, sum(cue.result)
FROM CatUserEvent cue
WHERE cue.date > :fromDate
  AND cue.catType != 0
  AND cue.result <= 4
GROUP BY cue.chat.id

Буду меньше краснеть.

💭 Вы ведёте своего бота, который обслуживает тысячи чатов.
У вас аккуратная база, которая хранит id'шники чатов и пользователей.
Вы сохраняете свойства пользователей, чатов и даже свойства связи пользователь-чат, например, пользователь что-то сделал в конкретном чате.
И в какой-то момент вы начинаете получать вот такое сообщение от телеграмма

[400] Bad Request: group chat was upgraded to a supergroup chat

И вся ваша база, со всеми своими связями и значениями становится неактуальной для конкретно этого чата. Телеграм вдруг решил поменять id чата, а вы напрасно его использовали в качестве первичного ключа в своей БД.
Ну и приходится писать код, который будет переносить\объединять сущности.
Например, параметр денег надо суммировать.
А всего у бота 80 параметров, и с каждым надо что-то делать. Удалить например
Зачем я это всё пишу? А просто пожаловаться на то, как телега внезапно подбрасывает проблемы, и что бывает, когда вы решаете завязаться на чужие первичные ключи.

Чуть не забыл, это же еще надо делать на реальной базе, потому что чатов тысячи и у всех свои условия. А еще у бота, на котором вы тестируете, нет доступа в нужные чаты, но бекапы БД помогут.

Работаю сейчас над анализом квестов и был крайне удивлён, обнаружив количество вариантов прохождения квеста с поездкой на поезде 🤯

Когда я начинаю разработку любого пет-проекта, требующего хранения данных в базе, я обычно использую H2. Она встроена в само приложение, т.е. не требует дополнительной инфраструктуры, но поддерживает всё необходимое. При этом есть удобный функционал по созданию бэкапа «из коробки». Уже много лет Котобот раз в сутки присылает мне бэкап БД в Телеграм. Точно так же я могу накатить базу данных из Телеги одной командой. Уже много раз это помогало сохранить пользовательские данные и откатывать сложный релиз при необходимости.

И вот до этого момента у меня ни разу не было необходимости переходить на что-то более мощное или зрелое — до этого момента. Сейчас база Котобота разрослась, и в таблице котособытий около миллиона записей, а сканирование с несколькими джойнами уже занимает секунды. Думаю о переезде на PostgreSQL, но придётся что-то придумывать с автоматическим бэкапом, переездом и развёртыванием.

А какие БД вы используете для собственных pet-проектов?