Extensão — Dados que Sobrevivem: Integrando SQLite com RAII

No artigo Extensão — C++ no Mundo da Web e da Persistência mapeamos o território de C++ na web e na persistência. Hoje pisamos nele: integramos o SQLite a um programa C++, criando um banco de dados real, em disco, cujos dados sobrevivem ao fim do programa. Nosso banco do capstone era brilhante mas volátil — desligou, evaporou. O SQLite é seu irmão persistente: um banco relacional completo que vive num único arquivo. E faremos a integração do jeito C++: o SQLite tem uma API em C puro, cheia de sqlite3_open, sqlite3_close e ponteiros a gerenciar à mão — exatamente o tipo de código que o curso inteiro ensinou a domar. Vamos envolvê-la em classes RAII (Fase 2), transformando a API C bruta em código C++ seguro. É a prova viva de que os princípios que você domina resgatam até bibliotecas legadas — e o momento em que seu conhecimento ganha persistência real.

A API C do SQLite: poderosa e perigosa

O SQLite é distribuído como uma biblioteca C. Sua API é eficiente mas tem os perigos clássicos do C que você conhece: você abre a conexão e é obrigado a fechá-la, gerencia ponteiros manualmente, e checa códigos de retorno a cada passo. Um uso cru se pareceria com isto — e repare no desconforto:

// Estilo C cru — funciona, mas é PERIGOSO (não faça assim em C++).
#include <sqlite3.h>
#include <iostream>

int main() {
    sqlite3* db = nullptr;
    if (sqlite3_open("dados.db", &db) != SQLITE_OK) {   // abre; checa código de retorno
        std::cerr << "erro ao abrir\n";
        return 1;
    }
    // ... usar db ...
    // Se um 'return' antecipado ou exceção ocorrer AQUI, o close abaixo é pulado
    // e a conexão VAZA — o problema de sempre do gerenciamento manual.
    sqlite3_close(db);   // precisa lembrar SEMPRE, em todos os caminhos
    return 0;
}

É o fopen/fclose do artigo Nascimento e Morte de um Objeto — Construtores, Destrutores e o RAII na Prática de novo, e o malloc/free da Fase 2: um recurso que você adquire e precisa liberar à mão, com todos os riscos de esquecer. A solução é a que você já domina — RAII.

Envolvendo a conexão em RAII

Criamos uma classe BancoSQLite que abre a conexão no construtor e a fecha no destrutor. A partir dela, a conexão nunca vaza, porque a liberação está amarrada ao fim de vida do objeto:

// banco_sqlite.h
#pragma once
#include <sqlite3.h>
#include <string>
#include <stdexcept>

class BancoSQLite {
public:
    // Construtor: ADQUIRE o recurso (abre a conexão). Lança se falhar.
    explicit BancoSQLite(const std::string& caminho) {
        if (sqlite3_open(caminho.c_str(), &db_) != SQLITE_OK) {
            std::string msg = sqlite3_errmsg(db_);
            sqlite3_close(db_);   // fecha o que foi parcialmente aberto
            throw std::runtime_error("SQLite: falha ao abrir: " + msg);
        }
    }

    // Destrutor: LIBERA o recurso (fecha a conexão). Roda SEMPRE, automaticamente.
    ~BancoSQLite() {
        if (db_) sqlite3_close(db_);
    }

    // Proíbe cópia: uma conexão tem UM dono (como unique_ptr — Fase 2).
    BancoSQLite(const BancoSQLite&) = delete;
    BancoSQLite& operator=(const BancoSQLite&) = delete;

    // Permite MOVIMENTO: transferir a posse da conexão (Fase 2).
    BancoSQLite(BancoSQLite&& outro) noexcept : db_(outro.db_) {
        outro.db_ = nullptr;   // o movido não deve fechar o que já não é seu
    }

    // Executa um comando SQL simples (sem resultados a ler).
    void executar(const std::string& sql) {
        char* erro = nullptr;
        if (sqlite3_exec(db_, sql.c_str(), nullptr, nullptr, &erro) != SQLITE_OK) {
            std::string msg = erro ? erro : "erro desconhecido";
            sqlite3_free(erro);   // a API C exige liberar a mensagem de erro
            throw std::runtime_error("SQLite: erro ao executar: " + msg);
        }
    }

    sqlite3* handle() const { return db_; }   // acesso ao handle bruto, quando necessário

private:
    sqlite3* db_ = nullptr;   // o recurso possuído
};

Contemple quanta coisa do curso está aqui. RAII (construtor adquire, destrutor libera — Fase 2). Cópia proibida e movimento permitido, exatamente como o unique_ptr (Regra dos Cinco, artigo Quando Copiar Dá Errado — a Regra dos Três e dos Cinco) — a conexão é um recurso de dono único. Exceções para reportar falhas de abertura e execução (Fase 6). const-correctness no handle() (Fase 3). O .c_str() para passar std::string à API C que espera const char* (Fase 1, artigo O Fim do char — Textos de Verdade com std::string). Esta classe é* o curso, aplicado a uma biblioteca real. E o resultado: quem usa BancoSQLite nunca vaza uma conexão, nunca esquece um close — a segurança é garantida por construção.

Persistência de verdade: dados que sobrevivem

Agora o momento da verdade. Vamos criar uma tabela, inserir dados, e — o ponto crucial — verificar que eles persistem entre execuções do programa:

// main.cpp
#include "banco_sqlite.h"
#include <iostream>

int main() {
    // Abre (ou cria, se não existir) o arquivo de banco.
    BancoSQLite banco("usuarios.db");

    // Cria a tabela se ainda não existir (SQL real).
    banco.executar(
        "CREATE TABLE IF NOT EXISTS usuarios ("
        "  id INTEGER PRIMARY KEY,"
        "  nome TEXT NOT NULL,"
        "  idade INTEGER"
        ")");

    // Insere dados — que serão GRAVADOS EM DISCO.
    banco.executar("INSERT INTO usuarios (nome, idade) VALUES ('Ana', 30)");
    banco.executar("INSERT INTO usuarios (nome, idade) VALUES ('Bruno', 25)");

    std::cout << "dados inseridos e persistidos em usuarios.db\n";
    return 0;
    // A conexão fecha AUTOMATICAMENTE aqui (destrutor de 'banco').
}

Rode este programa duas vezes. Na primeira, ele cria o arquivo usuarios.db e insere os dados. Na segunda, o arquivo já existe, a tabela já está lá (graças ao IF NOT EXISTS), e as novas inserções se somam às antigas — porque os dados da primeira execução sobreviveram no disco. Essa é a diferença fundamental do banco em memória do capstone: aqui, os dados persistem. Você fechou o programa, desligou o computador, e os registros continuam lá, num arquivo que você pode copiar, versionar, ou abrir com qualquer ferramenta SQLite. É a persistência real, envolvida em código C++ seguro.

A honestidade sobre esta integração

Prometo a franqueza de sempre. Mantive o exemplo deliberadamente simples para focar no princípio (RAII sobre a API C), e devo ser transparente sobre o que não mostrei. Primeiro, ler resultados de consultas (SELECT) no SQLite é mais elaborado que executar comandos — envolve "preparar" a consulta, iterar sobre as linhas de resultado com sqlite3_step, e extrair cada coluna; isso também deveria ser envolvido em RAII (uma classe Consulta que gerencia o statement preparado), e o exercício 4 pede exatamente isso. Segundo, montar SQL concatenando strings — como fiz com valores fixos aqui — é perigoso com dados de entrada reais: abre a porta para injeção de SQL, uma das vulnerabilidades de segurança mais clássicas; em código de produção, usa-se prepared statements com parâmetros ligados (?), que separam o comando dos dados. Não mostrei isso para não sobrecarregar, mas é essencial, e o menciono porque omiti-lo sem aviso seria irresponsável. Terceiro, existem wrappers C++ prontos para o SQLite (como o SQLiteCpp) que já fazem todo esse trabalho de RAII por você — usá-los é o que se faz na prática; construímos o nosso aqui pelo valor pedagógico de ver o princípio em ação. A lição fica: os conceitos do curso domam APIs C, mas o mundo real tem camadas adicionais (segurança, leitura de resultados) que uma introdução apenas aponta.

Envolver a API C do SQLite numa classe é o exercício mais honesto de RAII do curso: um recurso real, de biblioteca de terceiros, que precisa ser fechado. Proibir cópia e permitir movimento não é formalidade — dois objetos com o mesmo sqlite3* fechariam a conexão duas vezes. E a parte que não é sobre C++: concatenar valores no SQL abre injeção, e o que previne isso são declarações preparadas com parâmetros ligados, não escape manual.

Fontes e leituras recomendadas

• sqlite.org/cintro.html: a introdução oficial à API C do SQLite, com open, exec, prepare e step.
• github.com/SRombauts/SQLiteCpp: o wrapper C++ RAII para SQLite, que faz na prática o que esboçamos — vale estudar seu código.
• sqlite.org/lang.html: a referência da linguagem SQL suportada pelo SQLite, para escrever suas consultas.
• "SQL Injection" (owasp.org): sobre a vulnerabilidade mencionada e por que prepared statements são essenciais.
• Anthony Williams e Scott Meyers: revisitar RAII e a Regra dos Cinco, cujos princípios sustentam a classe BancoSQLite.

Exercícios

Exercício 1

Compile e rode o exemplo desta aula duas vezes (você precisará ter o SQLite instalado e linká-lo: -lsqlite3). Confirme que os dados se acumulam entre execuções, provando a persistência. Descreva o que observou.

Exercício 2

Explique como a classe BancoSQLite aplica RAII para tornar segura a API C do SQLite. Que problema concreto do uso cru (mostrado no início da aula) ela elimina?

Exercício 3

Explique por que BancoSQLite proíbe a cópia mas permite o movimento. O que daria errado se a cópia fosse permitida e dois objetos BancoSQLite compartilhassem o mesmo sqlite3*?

Exercício 4

Esboce uma classe Consulta que envolva um prepared statement do SQLite em RAII (o statement é criado com sqlite3_prepare_v2 e destruído com sqlite3_finalize). Descreva quais métodos ela teria para executar uma consulta SELECT e iterar sobre os resultados.

class Consulta {
public:
    // Construtor: PREPARA o statement (adquire o recurso).
    Consulta(BancoSQLite& banco, const std::string& sql) {
        if (sqlite3_prepare_v2(banco.handle(), sql.c_str(), -1, &stmt_, nullptr) != SQLITE_OK)
            throw std::runtime_error("falha ao preparar consulta");
    }
    // Destrutor: FINALIZA o statement (libera o recurso).
    ~Consulta() { if (stmt_) sqlite3_finalize(stmt_); }

    Consulta(const Consulta&) = delete;             // dono único
    Consulta& operator=(const Consulta&) = delete;

    // Avança para a próxima linha de resultado; devolve true se há linha, false no fim.
    bool proxima_linha() { return sqlite3_step(stmt_) == SQLITE_ROW; }

    // Extrai valores da linha atual, por índice de coluna.
    int64_t coluna_int(int i) { return sqlite3_column_int64(stmt_, i); }
    std::string coluna_texto(int i) {
        return reinterpret_cast<const char*>(sqlite3_column_text(stmt_, i));
    }
private:
    sqlite3_stmt* stmt_ = nullptr;
};

Exercício 5

A aula alerta sobre injeção de SQL ao concatenar strings. Explique o que é essa vulnerabilidade com um exemplo concreto (um valor malicioso), e descreva como prepared statements com parâmetros ligados a previnem.