Construindo softwares.

A construção de softwares.

Construção desde o baixo nível até o alto nível dentro de um sistema operacional modelo UNIX.

Entendendo e relacionando bibliotecas.

Python a pypi.

A contrução de uma biblioteca simples mas muito útil com certeza.

Na construção dela foi adotada uma linguagem que hoje em dia está acassível a muitos. **python.**

Nossa biblioteca, o código se encontra livre e buscando atender as conformidades com as legislações e licensas vigentes.

Ela pode ser instalada através da própria pip.

Independente de outrod probelmas algumas das falhas da library(biblioteca são intencionais pois a finalidade é em partes educacional.

Aqui o projeto dentro da comunicade e métodos de publicação oficiais.

https://codeberg.org/Linux77/dStorage

Aqui o repositório git para onde migrei o projeto a migração ainda não está totalmente concluída pois ainda preciso me aprimorar em muitas tarefas.

dStorage — Análise do Repositório

Visão Geral

O dStorage é uma biblioteca Python desenvolvida por Leonardo de Araújo Lima, da Academia do Software Livre (São Lourenço – MG). O objetivo é ser uma metaclasse base que automaticamente gera interfaces GUI (Tkinter) e CLI para classes que precisam de persistência em banco de dados SQLite.

🏗️ Arquitetura

O projeto é simples e centralizado em um único arquivo principal:

dStorage/
├── dStorage/
│   ├── core.py        ← Toda a lógica da biblioteca
│   └── __init__.py    ← Apenas define a versão
├── examples/
│   ├── 1stApp.py      ← Exemplo de cadastro via GUI
│   └── 2stApp.py      ← Exemplo de leitura/exibição
└── pyproject.toml     ← Build com Flit

⚙️ O que a classe `dStorage` faz

A classe recebe dois arrays paralelos no construtor — pindex (nomes dos campos) e pdata (valores) — e oferece:

Método	Função
`cdBase()`	Cria a tabela no SQLite dinamicamente
`savedata()`	Insere um registro via SQL
`loaddata(id)`	Carrega um registro por ID
`deletedata(id)`	Remove um registro por ID
`cad()`	Abre formulário GUI (Tkinter) para inserção
`registrar()`	Cadastro via terminal (CLI)
`display()`	Exibe dados em janela Tkinter
`show()`	Exibe dados no terminal
`getid(campo, valor)`	Busca ID por valor de campo
`litems()`	Lista todos os IDs da tabela

🐛 Problemas Encontrados

Bugs críticos:

version como atributo e método ao mesmo tempo — self.version = "1.1.3rc1" no __init__ sobrescreve o método version(self), tornando-o inacessível.
setdb() com lógica invertida — A condição if len(self.dpath) > 1 deveria levar ao uso de dpath, mas dentro do else é que set_database() é chamado. A lógica está trocada.
getid() tem código morto — c.commit() e con.close() após um return nunca serão executados.
loaddata() com bug de iteração — O loop for row in c.fetchone() itera sobre os campos de um registro (não sobre registros), e reatribui self.pdata a cada iteração, resultando em apenas o último campo.
SQL Injection — Vários métodos como getid() e lnames() concatenam strings diretamente no SQL sem sanitização, o que é uma vulnerabilidade grave mesmo para uso pessoal.

Problemas de qualidade:

requirements.txt com centenas de dependências do sistema operacional inteiro (Debian/Ubuntu), sem relação com a biblioteca em si — parece um pip freeze do ambiente completo.
Sem tratamento de erros (try/except) em nenhuma operação de banco de dados.
debug = 1 hardcoded no construtor, com vários print() de depuração sempre ativos.
Comentários misturados em inglês e português.
Licença duplicada (LICENSE e LICENSE.txt) com anos de copyright inconsistentes (1983?).

✅ Pontos Positivos

Ideia interessante: a geração automática de formulários a partir dos campos da classe é um conceito válido e útil para prototipagem.
Código legível: apesar dos bugs, a intenção de cada método é clara.
Publicado no PyPI: o projeto está empacotado corretamente com Flit e disponível para instalação via pip.
Licença livre: GPL v3, com intenção clara de ser software aberto.
Exemplos incluídos: os dois exemplos na pasta examples/ demonstram bem o uso básico.

💡 Sugestões de Melhoria

Usar parameterized queries em todo o SQL para eliminar a SQL Injection: # Em vez de: “WHERE ” + name + “='” + value + “‘” # Use: “WHERE ? = ?”, (name, value)
Separar o requirements.txt em apenas as dependências reais (basicamente apenas tkinter, que é built-in).
Renomear version para _version ou usar @property para evitar o conflito.
Adicionar try/except em todas as operações SQLite.
Tornar debug configurável pelo construtor em vez de hardcoded.

📊 Resumo

Aspecto	Avaliação
Conceito/Ideia	⭐⭐⭐⭐ Boa proposta educacional
Código	⭐⭐ Bugs importantes presentes
Segurança	⭐ SQL Injection em múltiplos pontos
Documentação	⭐⭐⭐ README razoável
Empacotamento	⭐⭐⭐ Funcional, mas requirements problemático
Maturidade	⭐⭐ Projeto de estudo/aprendizado (como o próprio autor declara)

O autor é bastante transparente que este é um projeto de estudos, e nesse contexto o repositório cumpre bem o papel de explorar a integração entre SQLite, Tkinter e CLI em Python. Para uso em produção, os pontos acima precisariam ser endereçados.