1База користувачів бота

Досі твій бот нічого не пам’ятає: відповів — і забув, хто писав. Сьогодні в нього з’явиться база даних — файл ~/data/app.db з таблицею users. Кожне повідомлення бот записуватиме туди сам: хто написав (номер чату, ім’я й нік у Telegram), коли вперше, коли востаннє і скільки разів. Оля пише вдруге — бот не заводить нову Олю, а додає одиницю до її лічильника.

Ти створиш таблицю однією командою, навчишся заглядати в неї програмою sqlite3 і писати запити мовою SQL, додаси в bot.py функцію remember(), а ще новий файл contacts.py з командою /users: напишеш її боту — і він відповість списком людей із бази. Наприкінці покажеш три речі: у базі щонайменше п’ятеро людей; ще одне повідомлення боту — і лічильник у рядку цієї людини виріс; у відповіді на /users рівно стільки людей, скільки рядків у таблиці.

Якщо в тебе немає TelegramСьогоднішнє заняття майже повністю робиться без нього: «людей» ти змоделюєш через try_bot.py, і автоперевірка теж пише боту саме так. Пропусти лише розмову з живим ботом у кроці 10.

Найпростіша ідея — файл users.txt, по рядку на людину: 123456789;Оля;7 — номер чату, ім’я, скільки повідомлень. Для п’ятьох однокласників це навіть працюватиме. А тепер подивись, що доведеться робити боту на кожне повідомлення.

1. Знайти людину. Програма читає файл від першого рядка, розрізає кожен на частини й порівнює номер. Тисяча людей — тисяча розрізань на кожне повідомлення.
2. Змінити одне число. Оля написала увосьме: 7 треба замінити на 8. Переписати шматок посеред файлу не можна — особливо коли 9 стає 10 і рядок довшає, — тож програма переписує весь файл. Уб’ють процес посеред запису (автоперевірка на занятті 02 саме так і робила) — від файлу лишиться половина.
3. Двоє одночасно. До твоїх даних ходять кілька програм: потік бота всередині служби, try_bot.py, який ти запускаєш руками, автоперевірка, а сьогодні ще й команда /users, що читає список. Дві програми прочитали файл в одну мить, кожна додала одиницю й записала свою версію — і та, що записала пізніше, стерла зміну першої. Одне повідомлення зникло з обліку, і ніхто про це не дізнався.
4. Жодних правил. У файл можна записати людину без імені, ім’я з крапкою з комою всередині (і зламати розрізання) чи слово «сім» замість числа. Помітиш через тиждень, коли підсумки не зійдуться.

База даних — програма, яка зберігає дані в таблицях і відповідає на запити до них. На кожну з чотирьох бід у неї є відповідь:

• людину за номером вона знаходить за індексом — службовим довідником «значення → де лежить рядок», не переглядаючи всіх рядків. Як предметний покажчик наприкінці підручника;
• зміни робить транзакцією — групою дій, що виконується або вся, або ніяк. Вимкнули світло посеред запису — після ввімкнення база така, якою була до початку транзакції, без половинок;
• на час запису ставить блокування: друга програма не пише одночасно з першою, а чекає своєї черги. У нашому db.py чекання обмежено десятьма секундами (timeout=10); не дочекалася — помилка database is locked, а не тихо зіпсовані дані;
• правила ти описуєш один раз, коли створюєш таблицю, і далі база сама відмовляє всьому, що їх порушує.

Ми беремо SQLite («ес-кю-лайт») — базу, яка тримає все в одному файлі й не потребує окремої служби: її вміє відкривати сам Python. Твій файл — ~/data/app.db, поруч із bot_state.json із заняття 02. Заглядати в нього руками ти будеш програмою sqlite3, яка вже стоїть на сервері. Не плутай: sqlite3 у терміналі — програма для людини, а import sqlite3 у Python — модуль для програми. Відкривають вони той самий файл.

Коли Оля вперше пише боту, база про неї нічого не знає. Ось що відбувається — крок за кроком, від повідомлення до рядка:

1. Оля пише боту «привіт»
2. Telegram віддає боту оновлення: у ньому chat.id = 123456789 і ім'я «Оля»
3. Бот питає базу: «чи є вже рядок з chat_id = 123456789?»
4. Немає  → бот додає новий рядок: (123456789, "Оля", перший візит = зараз, повідомлень = 1)
   Вже є  → бот лише оновлює рядок: повідомлень = повідомлень + 1, останній візит = зараз
5. Бот відповідає Олі, а в таблиці users тепер видно, хто писав, коли й скільки разів

Тут є важлива ідея: унікальний ідентифікатор людини. Ім'я для цього не годиться — двох Оль може бути багато, а ім'я можна змінити. Тому людину впізнають за chat_id — числом, яке Telegram видає кожному акаунту і яке ніколи не повторюється. У таблиці на цьому стовпці стоїть правило UNIQUE (розділ 4): другої людини з таким самим номером не з’явиться. Саме за ним база знаходить «свою» людину. Чого бот не зберігає: паролів і того, що людина не просила запам'ятати (докладніше — у розділі про те, що бот має право пам'ятати).

Той самий принцип працює в усіх сайтах і застосунках: коли ти заходиш у соцмережу, вона шукає у своїй базі рядок із твоїм ідентифікатором — і або знаходить, і показує твій профіль, або створює новий.

Дані в базі лежать у таблицях. Одна таблиця — один вид речей; у нас це люди, які писали боту, і таблиця зветься users («користувачі»). Далі три слова будуть майже в кожному реченні:

• рядок, або запис, — одна людина з усіма її даними;
• стовпець, або поле, — одна характеристика, яка є в кожного рядка: ім’я, час, лічильник;
• схема — опис таблиць: які стовпці, якого типу, з якими правилами. Її продумують до того, як з’являться дані: переробляти таблицю, у якій уже сотня людей, значно важче.

Ось схема нашої таблиці. Вона лежить у файлі init_db.py, який ти сьогодні скопіюєш. Рядки, що починаються з --, — коментарі SQL, як # у Python:

CREATE TABLE IF NOT EXISTS users (
    id         INTEGER PRIMARY KEY,
    chat_id    INTEGER UNIQUE,              -- порожнє, якщо контакт додано вручну
    name       TEXT    NOT NULL,
    username   TEXT    NOT NULL DEFAULT '',
    note       TEXT    NOT NULL DEFAULT '',
    first_seen TEXT    NOT NULL,
    last_seen  TEXT    NOT NULL,
    messages   INTEGER NOT NULL DEFAULT 0
);

Назви стовпців — латиницею, малими літерами, через підкреслення: вони стоять у кожному запиті й у коді. І в кожного рядка ті самі стовпці, що й у решти: окремого поля «улюблений колір» лише для Олі в таблиці не буває.

Тип даних — вид значення в стовпці. Нам потрібні два: INTEGER — ціле число і TEXT — текст будь-якої довжини (є ще REAL для дробових чисел і BLOB для файлів). Лічильник — число, бо до нього додають одиницю: запиши «сім» текстом — і додати вже не вийде. Окремого типу для дати й часу в SQLite немає, тому їх записують текстом, але в строгому порядку: рік-місяць-день, буква T, години:хвилини:секунди. Функція now() у твоєму bot.py дає саме такий запис:

2026-10-21T15:04:27

Чому саме так? Такий текст порівнюється й сортується так само, як час: зліва найстарший розряд — рік, далі місяць, день, година. "2026-10-21T09:05" більше за "2026-10-09T23:59" і як текст, і як дата. Тому ORDER BY last_seen DESC — «упорядкуй від найсвіжішого» — працює без жодних перетворень. А в записі 21.10.2026 першим стоїть день, і 21 жовтня опинилося б поруч із 21 березня.

CREATE TABLE IF NOT EXISTS означає «створи таблицю, якщо її ще немає». Є — команда нічого не робить і помилки не видає. Тому init_db.py можна запускати скільки завгодно разів: люди, які вже є в таблиці, нікуди не дінуться.

Оль у класі буває дві. Щоб база розрізняла рядки навіть тоді, коли всі інші поля однакові, у таблиці є первинний ключ (PRIMARY KEY) — стовпець, значення якого не повторюється й ніколи не буває порожнім. У нас це id. Тип INTEGER PRIMARY KEY має в SQLite зручну властивість: номер нового рядка база ставить сама, тож у запиті на додавання id не передають. Ключ не змінюється за все життя рядка: Оля змінить ім’я в Telegram — name зміниться, а id лишиться.

Порожнє поле в базі — окреме значення NULL, «нічого не записано». Воно не дорівнює ні нулю, ні порожньому рядку: messages = 0 — відомий факт «жодного повідомлення», а NULL — «невідомо». Правила для стовпців:

• NOT NULL — порожнім бути не може. Стоїть на name, first_seen, last_seen: людина без імені й без часу в обліку не має сенсу. Спробуєш додати такий рядок — база відмовить з помилкою NOT NULL constraint failed: users.name;
• UNIQUE — значення не повторюється. Стоїть на chat_id: одна людина в Telegram — один рядок у таблиці. Другий рядок з тим самим номером база не прийме: UNIQUE constraint failed: users.chat_id. Від первинного ключа відрізняється тим, що порожнє значення дозволене, і навіть у кількох рядках;
• DEFAULT — що підставити, якщо значення не передали: DEFAULT '' — порожній рядок, DEFAULT 0 — нуль. Тому username і note ніколи не бувають NULL, і програмі не треба окремо перевіряти «а раптом там нічого».

Чому ключ — окремий id, а не chat_id, адже номер чату й так унікальний? Бо він буде не в кожного рядка. На наступному занятті в таблицю можна буде додати контакт руками — людину, яка боту ще не писала й номера чату не має; про це й коментар у схемі: «порожнє, якщо контакт додано вручну». Первинний ключ мусить бути в кожного рядка, тому ним служить id, а chat_id лише UNIQUE.

Правила перевіряє не твій код, який можна забути чи зламати, а сама база — щоразу, хоч би хто писав: бот, try_bot.py чи ти руками.

SQL («ес-кю-ел») — мова запитів до бази. Ти описуєш, що хочеш отримати, а як дістати це з файлу, вирішує база. Ключові слова пишуть великими літерами, щоб їх було видно серед назв стовпців; база великих і малих літер у них не розрізняє. Запит закінчується крапкою з комою. Текст у запиті береться в одинарні лапки — 'Оля', числа пишуть без лапок. Першу команду, CREATE TABLE, ти вже бачив у розділі 2. Ще три:

INSERT — додати рядок. Спершу перелік стовпців, потім значення в тому самому порядку:

INSERT INTO users(chat_id, name, first_seen, last_seen)
VALUES(555, 'Оля', '2026-10-21T15:04:27', '2026-10-21T15:04:27');

id не вказано — база поставить сама; username, note і messages не вказано — підставить значення з DEFAULT.

SELECT — дістати рядки:

SELECT * FROM users;
SELECT name, messages FROM users WHERE messages >= 5;
SELECT * FROM users ORDER BY last_seen DESC;
SELECT name FROM users ORDER BY messages DESC LIMIT 3;
SELECT COUNT(*) FROM users;

• * — усі стовпці; замість зірочки можна перелічити потрібні через кому;
• FROM users — з якої таблиці;
• WHERE — умова: у відповідь потраплять лише рядки, для яких вона правдива. Порівнюють знаками =, !=, <, >, <=, >=;
• ORDER BY … DESC — упорядкувати від більшого до меншого; без DESC — від меншого до більшого;
• LIMIT 3 — не більше трьох рядків. Зручно для «трійки найактивніших», але в запиті списку йому не місце: список має віддавати всіх;
• COUNT(*) — не самі рядки, а їхня кількість: відповідь з одного числа.

UPDATE — змінити рядки, які вже є:

UPDATE users SET note = 'сидить зі мною за партою' WHERE chat_id = 555;

Читається так: «онови таблицю users: у полі note хай буде такий текст — там, де chat_id дорівнює 555». Без WHERE зміниться кожен рядок таблиці, і база нічого не перепитає. Тому спершу продумай WHERE, а вже потім — що міняти.

Тепер головне для бота. На кожне повідомлення йому треба: людини ще немає — додати, уже є — оновити час і лічильник. Можна спершу спитати базу через SELECT, а потім вирішити, — але це два запити, зайвий код, і між ними може втрутитися інша програма. SQLite вміє все це одним запитом: INSERT … ON CONFLICT … DO UPDATE — «спробуй додати, а якщо вийде конфлікт із правилом UNIQUE, онови рядок, який уже є». Ось функція remember(), яку ти сьогодні додаси в bot.py:

# ── заняття 04: база користувачів бота ──────────────────────────────
def remember(sender):
    """Записує або оновлює того, хто написав боту. Зберігаємо мінімум:
    chat_id, ім'я, нік, коли вперше й востаннє писав і скільки повідомлень."""
    from db import execute
    if not sender.get("id"):
        return
    t = now()
    execute("""INSERT INTO users(chat_id, name, username, first_seen, last_seen, messages)
               VALUES(?, ?, ?, ?, ?, 1)
               ON CONFLICT(chat_id) DO UPDATE SET
                 name=excluded.name, username=excluded.username,
                 last_seen=excluded.last_seen, messages=users.messages + 1""",
            (sender["id"], sender.get("first_name") or "без імені",
             sender.get("username") or "", t, t))

• sender — словник from з оновлення Telegram: {"id": 123456789, "first_name": "Оля", "username": "olia_k", …};
• from db import execute — бере з db.py функцію, що виконує запит і зберігає зміни. Стоїть усередині remember(), тож db.py підключається, лише коли бот справді щось записує;
• if not sender.get("id"): return — запобіжник: немає номера відправника — нема кого записувати. Telegram і try_bot.py номер передають завжди;
• t = now() — один час для двох полів: у нового рядка first_seen і last_seen однакові. П’ять знаків ? у VALUES — місця для п’яти значень, що лежать окремо, у дужках унизу, у тому самому порядку: номер, ім’я, нік, час, час. Шосте, 1, вписане прямо в запит — це перше повідомлення людини. Чому знаки питання — у наступному розділі;
• ON CONFLICT(chat_id) DO UPDATE SET … — що робити, коли такий chat_id уже є. excluded — рядок, який ми намагалися додати, а users — той, що вже лежить у таблиці. Тож ім’я, нік і час останнього повідомлення беремо нові, а лічильник — старий плюс один;
• first_seen у переліку після SET немає, тому він не змінюється ніколи. Як і note: твою примітку бот не зітре;
• sender.get("first_name") or "без імені" — ім’я з Telegram, а якщо його чомусь немає — запасне слово, бо name у нас NOT NULL.

Потрійні лапки """…""" — рядок Python на кілька рядків: увесь запит — один текст, який Python передає базі як є. І ще: ON CONFLICT(chat_id) спрацьовує лише тому, що на chat_id стоїть UNIQUE. Без цього правила базі нема з чим «конфліктувати», і вона відповість помилкою ON CONFLICT clause does not match any PRIMARY KEY or UNIQUE constraint.

Як користуватися ШІ-помічникомШІ добре пояснює SQL: «розбери цей запит по словах», «чим excluded відрізняється від users». Можна попросити й написати запит — але кожен спершу виконай сам у sqlite3 і подивись, що він повернув. Особливо UPDATE: без WHERE він змінить усю таблицю. І ніколи не вставляй у чат вміст своєї бази: там імена й ніки однокласників, а це не твої дані.

Чому в remember() стоять знаки питання, а не f-рядок на зразок f"… VALUES({chat_id}, '{name}', …)"? Згадай, звідки береться name: це ім’я, яке людина сама вписала у свій профіль Telegram. Твоя програма його не вибирає й не перевіряє. Хай однокласниця записана як Мар'яна — зі звичайним прямим апострофом. Склеєний запит вийшов би таким:

INSERT INTO users(chat_id, name, …) VALUES(777, 'Мар'яна', …)

Апостроф у імені закрив лапки зарано: для бази текст закінчився на 'Мар', а далі стоїть незрозуміле яна'. Python отримає помилку sqlite3.OperationalError: near "яна": syntax error, і бот замість привітання напише «Ой, щось пішло не так». Це ще безневинний випадок. Якщо дані вміють закривати лапки, ними можна дописати в запит чужі SQL-команди: показати рядки, яких не мали показувати, змінити їх чи стерти. Така атака зветься SQL-ін’єкцією («впорскуванням»), і роками вона була однією з найчастіших причин витоків даних із сайтів.

Захист простий і надійний: значення ніколи не вклеюють у текст запиту. На місці кожного стоїть ? — параметр, а самі значення йдуть окремо, другим аргументом:

execute("UPDATE users SET note = ? WHERE chat_id = ?", ("сидить поруч", 555))

База спершу розбирає текст запиту — у ньому немає жодного символу від користувача, — а значення підставляє вже потім, як дані, а не як команду. Хоч би що людина вписала в ім’я, воно ляже в поле name буква в букву, разом з апострофами й крапками з комою. Звідси правило на весь курс: текст запиту пишеш ти, дані приходять через ?. На занятті 08 ти перевірятимеш на міцність свій сервіс — і це правило там знадобиться.

У db.py для роботи з базою є три функції, і всі приймають запит і окремо параметри:

• query(sql, params) — для SELECT: повертає список словників, по одному на рядок, де ключі — назви стовпців: [{"id": 1, "name": "Оля", …}, …];
• execute(sql, params) — для INSERT і UPDATE: виконує запит, зберігає зміни й повертає id доданого рядка;
• changed(sql, params) — теж змінює, але повертає, скільки рядків змінилося (0 — такого запису немає). Вона з’явилася в новій версії db.py і знадобиться на наступному занятті.

Усі три відкривають базу через connect(), а шлях беруть із DB_PATH: ~/data/ плюс ім’я з database.file у project.yaml. Задано змінну оточення APP_DB — шлях береться з неї: так пізніше тести працюватимуть на окремій базі, не чіпаючи справжньої. А with connect() as conn: — це транзакція з розділу 1: усе вийшло — зміни записано, щось упало — скасовано.

SQL-база (SQLite, PostgreSQL, MySQL) — це таблиці з чітко заданими стовпцями: у кожного рядка однаковий набір полів і типів, а між таблицями можна задавати зв’язки (наприклад, «у цього користувача три замовлення»). Для списку людей, що пишуть боту, це ідеально: усі мають chat_id, ім'я й лічильник, а мова SQL дозволяє одним запитом дізнатися «хто писав найбільше» чи «скільки людей писало сьогодні». База сама стежить за правилами (NOT NULL, UNIQUE) і не дає записати сміття. SQLite ще й живе просто в одному файлі — на нашому спільному сервері це найпростіше й найекономніше.

NoSQL («не тільки SQL») — назва для баз, які зберігають дані не таблицями. Замість жорстких стовпців — гнучкі записи, де в кожного може бути свій набір полів. Є кілька видів — ось приклади з життя:

Приклад: у соцмережі твоє ім'я, пароль і дата реєстрації лежать у SQL-таблиці — це суворі, важливі дані. А стрічка новин, де в кожного допису різні поля (текст, фото, відео, опитування) — зручніше в документній NoSQL-базі. А «хто зараз онлайн» тримають у Redis, бо це треба читати тисячі разів на секунду. Одна велика програма часто користується кількома базами одразу.

Коротка відповідь, що вибрати: немає «кращого» — є «доречніший». Для нашого бота дані прості й однакові (людина, ім'я, лічильник), важлива точність, і треба вміти робити підрахунки, тому ми беремо SQL. NoSQL варто згадати, коли дані дуже різні за формою, коли їх надзвичайно багато або коли потрібна швидкість понад усе.

Усе, за чим можна впізнати конкретну людину, — ім’я, нік, номер чату, коли й скільки вона писала, — це персональні дані. Їх захищають закони: в Україні — закон «Про захист персональних даних», у Європейському Союзі — закон GDPR (загальний регламент про захист даних). Головні вимоги там схожі: збирай лише те, без чого справді не обійтися, кажи людям, що збираєш, і бережи зібране.

Нашому боту для обліку досить кількох речей: номер чату (щоб упізнати людину вдруге), ім’я й нік (щоб ти розумів, хто це), час першого й останнього повідомлення та лічильник. Ось чого в таблиці немає і бути не повинно:

• текстів повідомлень. Люди пишуть боту різне, інколи особисте, а лічильнику текст не потрібен. Повідомлення, збережене в базі, — це повідомлення, яке хтось колись може прочитати;
• номера телефона, прізвища, школи, адреси. Бот їх не бачить, доки людина сама не надішле, і просити їх не треба: для обліку вони ні до чого;
• фото профілю й геолокації — з тієї самої причини.

Друга вимога — прямота. Тому сьогодні в привітанні на /start з’явиться речення Я запам’ятовую твоє ім’я, нік, час повідомлень і скільки їх було. Людина, яка пише твоєму боту, має знати, що її записано.

Третя — берегти. І тут поки є слабке місце, про яке треба знати: команда /users, яку ти сьогодні зробиш, відповідає кожному, хто знайде твого бота й напише її. Імена й ніки всіх, хто писав, побачить будь-хто. Зараз так навмисно, лише для навчання: простіше побачити, як рядки з бази стають відповіддю бота. На занятті 07 ти залишиш список лише собі. А до того — дві домовленості: однокласники пишуть твоєму боту, знаючи, що їхнє ім’я з’явиться у списку, а нік свого бота ти не розсилаєш нікому поза групою.

І про chat_id: це не пароль, як токен, — знаючи номер, чужа людина не зайде у твій Telegram. Але номер у людини один для всіх ботів, тож за ним її можна впізнати в різних базах. Тому це теж персональні дані.

Кожне питання оцінюється відразу в браузері — це лишається так само. Ця кнопка лише надсилає підсумок учителю, щоб відповіді не зникли разом із закритою вкладкою.

Список критеріїв і що саме вони означають — у таблиці вище, «Що перевіряє автоматика». Тут — та сама перевірка, але прямо зараз, без очікування на найближчий прохід за розкладом.

1. Команда /me — «що ти про мене знаєш?». Хай бот показує людині її власний рядок. У handle_update() вище за if text.startswith("/"): додай:

       if text.startswith("/me"):
           from db import query
           rows = query("SELECT messages, first_seen FROM users WHERE chat_id = ?",
                        (sender.get("id"),))
           if not rows:
               return "Я тебе ще не знаю."
           return (f"Повідомлень від тебе: {rows[0]['messages']}. "
                   f"Уперше ти написав {rows[0]['first_seen'][:10]}.")

   Номер чату йде в запит через ?, як у remember(). Кома в (sender.get("id"),) обов’язкова: так Python розуміє, що це набір з одного значення, а не просто дужки. [:10] бере перші десять символів часу — саму дату. Додай рядок /me у HELP, перевір python3 try_bot.py --id 2 --name Оля "/me" і перезапусти службу. Поясни, чому rows майже ніколи не буває порожнім (підказка: що відбувається з кожним повідомленням ще до перевірки команд?).
2. Три питання до своєї бази. У sqlite3 напиши запити, які відповідають: хто з людей написав боту найбільше (ORDER BY і LIMIT 1); скільки людей писали сьогодні (WHERE last_seen >= '2026-10-21' — з сьогоднішньою датою); у кого є нік (WHERE username != ''). Запиши запити й відповіді в чернетку — на початку наступного заняття викладач попросить виконати один із них.
3. Розділ про базу в README. Допиши в README.md розділ ## База даних: яка там таблиця, які в ній поля, що бот про людей не зберігає і чому. Три-п’ять речень своїми словами. Розділи ## Що це і ## Як запустити не чіпай — їх і далі перевіряють.
4. Поясни remember(). Підготуйся пояснити будь-який її рядок: що таке excluded і чим воно відрізняється від users, чому не змінюється first_seen, навіщо ? замість f-рядка і що станеться, якщо прибрати з таблиці UNIQUE.
5. Збережи. git add -A, git commit -m "Заняття 04: команда /me і розділ про базу в README", git push origin master і git push github master.

37Бот відповідає «Ой, щось пішло не так», а try_bot.py пише no such table: users

remember() звертається до таблиці, якої в базі немає. Подивись, що є насправді:

ls -l ~/data/app.db
sqlite3 ~/data/app.db ".tables"
grep -n "file:" ~/app/project.yaml
tail -n 30 ~/logs/club-bot.log | grep "помилка обробки"

• .tables нічого не друкує — таблиць не створено: cd ~/app && python3 init_db.py;
• у project.yaml не file: app.db — db.py відкриває інший файл. Поверни app.db, перезапусти службу;
• помилка називає іншу таблицю, наприклад no such table: user, — описка в запиті remember(). Порівняй з готовим: diff /opt/club/kurs/04/bot.py ~/app/bot.py.

Після виправлення перевір python3 try_bot.py "привіт" і зроби systemctl --user restart club-bot, щоб і живий бот узяв нову версію.

38sqlite3 показує порожню базу, хоча init_db.py сказав «таблиці готові»

Майже завжди це інший файл: команду набрано з коротким шляхом, наприклад sqlite3 app.db у теці ~/app. Тоді sqlite3 відкриває нову, порожню базу поруч із кодом. Перевір:

ls -l ~/app/*.db ~/data/app.db

Рядок cannot access '…/app/*.db' — добре: випадкових файлів бази в ~/app немає, і причину треба шукати в самій команді. Справжня база — лише ~/data/app.db. Якщо поруч є ~/app/app.db, він випадковий: видали саме його, уважно перевіривши шлях, — rm ~/app/app.db — і відтепер пиши повний шлях sqlite3 ~/data/app.db. У Git випадковий файл однаково не потрапив би: .gitignore не пускає туди *.db.

39L04.3 не зараховано: лічильник не росте

Повтори те, що робить автоперевірка, і подивись, чи зріс лічильник:

cd ~/app
python3 try_bot.py --id 1000000001 --name Автоперевірка "привіт"
sqlite3 ~/data/app.db "SELECT messages FROM users WHERE chat_id = 1000000001"
grep -n "remember" bot.py
grep -n "main_table:" project.yaml

• число не росте з кожним запуском — remember(sender) не викликається. grep має показати щонайменше два рядки: def remember(sender): і виклик remember(sender). Виклик має стояти одразу після if not text: return None, вище за всі команди (крок 8);
• main_table: не users — автоперевірка шукає лічильник в іншій таблиці (крок 3);
• ON CONFLICT clause does not match any PRIMARY KEY or UNIQUE constraint — описка в ON CONFLICT(chat_id) або таблицю колись створено іншою схемою, без UNIQUE. Подивись sqlite3 ~/data/app.db ".schema users". Якщо схема не така, як у init_db.py, а в таблиці поки лише змодельовані люди, створи її заново: sqlite3 ~/data/app.db "DROP TABLE users" (ця команда видаляє таблицю разом з усіма рядками), потім python3 init_db.py і знову п’ятеро людей із кроку 11.

40/users не працює або дає не те число (L04.5)

cd ~/app
python3 try_bot.py "/users"
sqlite3 ~/data/app.db "SELECT COUNT(*) FROM users"
grep -n "contacts" bot.py
grep -n "list:" project.yaml

Перша команда — відповідь бота, друга — скільки рядків у таблиці, третя й четверта — підключення команди й рядок маніфесту.

• Не знаю такої команди — бот не передав команду в contacts.py. grep має показати import contacts і contacts.command(text, sender) у handle_update(), причому вище за рядок return "Не знаю такої команди…" (крок 13);
• ModuleNotFoundError: No module named 'contacts' — файл не скопійовано: cp /opt/club/kurs/04/contacts.py ~/app/;
• База зараз недоступна — users_text() упала на запиті. Пробуй окремо: sqlite3 ~/data/app.db "SELECT * FROM users ORDER BY last_seen DESC, id DESC"; найімовірніше, таблиці немає (крок 5) або в запиті описка;
• перший рядок відповіді не «Людей у базі: N» — автоперевірка шукає саме ці слова. Лиши їх такими, як у зразку;
• числа в кроці 14 різні — у запиті є LIMIT чи WHERE. Список має бути SELECT * FROM users ORDER BY last_seen DESC, id DESC — і нічого більше;
• у project.yaml порожнє list: "" — автоперевірка не знає, яку команду надсилати: впиши list: "/users".

41Термінал або sqlite3 чогось чекають і не відповідають

• на початку рядка з’явився знак > — термінал чекає закривної подвійної лапки: ти відкрив " і не закрив. Натисни Ctrl+C і набери команду знову;
• ти запустив sqlite3 ~/data/app.db без запиту — відкрилася розмова з базою із запрошенням sqlite>. Тут теж можна писати запити, але кожен закінчується ;. Забув крапку з комою — програма показує ...> і чекає продовження: набери ; і Enter. Вийти — .quit або Ctrl+D;
• bash: !…: event not found — у подвійних лапках опинився знак оклику: термінал сприйняв його як свою команду. Прибери ! з тексту.

42database is locked

Базу зайняла інша програма й не відпускала довше за десять секунд. На нашому сервері так буває, коли в іншому вікні термінала лишилася відкрита розмова sqlite3 з незакінченою зміною — наприклад, хтось набрав BEGIN;, потім UPDATE …;, а завершального COMMIT; не було. Поки зміну не завершено, база тримає чергу для всіх інших. Повернись у те вікно й набери COMMIT; (зберегти зміну) або .quit (вийти без неї). Потім повтори свою команду: бот і try_bot.py самі чекають на базу до десяти секунд, тож поодинока помилка мине. Якщо повторюється — systemctl --user restart club-bot і скажи викладачеві.

43У базі зайві або «тестові» рядки

Наприклад, ти вводив --name тест1 або однаковим людям дав різні --id. Знайди номери зайвих рядків і видали їх по одному командою DELETE — вона прибирає рядки, які підходять під WHERE:

sqlite3 -header -column ~/data/app.db "SELECT id, chat_id, name, messages FROM users"
sqlite3 ~/data/app.db "DELETE FROM users WHERE id = 7"

Замість 7 — id зайвого рядка. Як і з UPDATE: без WHERE зникне вся таблиця. Справжню людину видаляти марно — щойно вона напише боту знову, remember() додасть її як нову, з лічильником 1. Рядок Автоперевірка теж не видаляй: він повернеться з наступною перевіркою. Потім додай людей, яких бракує до п’ятьох (крок 11).