Download the PHP package velt/database without Composer

Velt Database - Module PDO Complet

Mise a jour Module 3 Data ORM

Le package contient maintenant les fondations database suivantes, sans modifier le repo veltphp-cli.

Query Builder

Toutes les valeurs dynamiques passent par des requetes preparees. Les noms de tables et colonnes sont valides comme identifiers SQL avant compilation.

Schema Builder et migrations

Le runner de migrations est disponible cote runtime :

Les commandes php bin/velt migrate, migrate:rollback, make:migration, make:seeder et db:seed doivent etre ajoutees dans veltphp-cli. Voir issues/06-cli-database-commands.md.

Seeders et factories

Cache de resultats

En environnement testing, DatabaseServiceProvider utilise un cache nul par defaut.

Vue d'ensemble

Ce module fournit une couche d'abstraction de base de données pour le framework Velt, implémentant les 5 premières étapes d'un système de gestion de base de données robuste et sécurisé.

Statut: Complet - 5/5 issues implémentées, 19 tests passants

Objectifs et raisons

Pourquoi ce module?

Le framework Velt nécessite une couche d'accès aux données centralisée, sécurisée et extensible:

• Sécurité: Prévenir les injections SQL via requêtes préparées obligatoires
• Maintenabilité: Isoler la logique de base de données du reste de l'application
• Flexibilité: Supporter plusieurs drivers (SQLite, MySQL, PostgreSQL)
• Performance: Mise en cache des connexions, pas de reconnexions inutiles
• Testabilité: Interfaces mockables et fakes pour les tests

Architecture générale

Composants implémentés

1. ConnectionFactory (src/ConnectionFactory.php)

Responsabilité: Construire les chaînes de connexion (DSN) et créer des instances PDO.

Pourquoi?

• Centraliser la logique de création PDO
• Supporter plusieurs drivers avec leurs syntaxes différentes
• Valider et documenter les paramètres requis pour chaque driver

Drivers supportés:

DSN générés:

Méthodes clés:

2. DatabaseManager (src/DatabaseManager.php)

Responsabilité: Gérer un pool de connexions nommées avec cache et initialisation lazy.

Pourquoi?

• Éviter de créer plusieurs PDO pour la même connexion
• Supporter plusieurs bases de données simultanément (ex: tenant separation)
• Résoudre la connexion par défaut automatiquement
• Valider la configuration au moment de l'accès, pas au démarrage

Fonctionnement:

Configuration attendue:

Méthodes clés:

3. DB (src/DB.php) - Facade statique

Responsabilité: Fournir une interface statique simple pour exécuter des requêtes.

Pourquoi?

• Accès au DatabaseManager depuis n'importe où sans DI
• Enforce obligatoire des requêtes préparées (pas de concat string)
• Méthodes nommées intuitives (select, first, statement)
• Support natif des transactions

Pattern utilisé: Facade statique avec délégation

Requêtes préparées obligatoires:

Méthodes disponibles:

Exemples:

4. Model (src/Model.php) - Classe de base MVP

Responsabilité: Fournir des méthodes CRUD simples pour accéder aux données.

Pourquoi MVP (Minimum Viable Product)?

• Débuter simple sans relations, dirty checking, ou mass assignment
• Laisser place pour extensions futures
• Couvrir les opérations basiques (trouver, lister, créer)

Utilisation:

Méthodes disponibles:

Limitations actuelles (MVP):

• Pas de relations (belongsTo, hasMany, etc.)
• Pas de dirty tracking (modification avant save)
• Pas de mass assignment protection
• Pas de validation built-in
• Pas de scopes ou query builder fluent

Ces fonctionnalités seront ajoutées dans les phases suivantes.

5. DatabaseServiceProvider (src/DatabaseServiceProvider.php)

Responsabilité: Enregistrer DatabaseManager dans le conteneur DI avec initialisation lazy.

Pourquoi un Service Provider?

• Pattern standard pour organiser les enregistrements DI
• Initialisation lazy: DatabaseManager créé seulement si utilisé
• Accès au ConfigRepository depuis le conteneur
• Préparé pour intégration avec kernel Velt

Enregistrement:

Utilisation dans le kernel:

Configuration

Structure attendue

Utilisation complète

Configuration du service provider

Utiliser DB (Facade)

Utiliser les Models

Tests

Exécuter les tests

Résultat attendu:

Structure des tests

Couverture de tests

Sécurité

Requêtes préparées obligatoires

Tous les accès à la base utilisent des prepared statements:

Pas de concaténation string:

Gestion des erreurs

Design Patterns utilisés

1. Factory Pattern

Centralise la création complexe

2. Service Provider Pattern

Organise l'initialisation des services

3. Facade Pattern

Simplifie l'utilisation depuis n'importe où

4. Singleton Pattern

Évite les connexions multiples

5. Dependency Injection

Testabilité et flexibilité

6. Repository Pattern

Découple de l'implémentation

Avantages de cette implémentation

📋 Issues implémentées

✅ Issue 01: DatabaseManager avec ConnectionFactory

• DSN builders pour SQLite, MySQL, PostgreSQL
• Gestion des erreurs et validation

✅ Issue 02: Query helper sécurisé

• Facade DB statique
• Prepared statements obligatoires
• Transactions avec commit/rollback

✅ Issue 03: BaseModel MVP

• Méthodes find(), all(), create()
• Configuration par table
• Prêt pour extensions

✅ Issue 04: Intégration configuration

• Lecture config en dot notation (database.connections.default)
• Support des drivers multiples
• Validation explicite

✅ Issue 05: DatabaseServiceProvider

• Enregistrement singleton
• Initialisation lazy
• Prêt pour kernel Velt

🚀 Prochaines étapes possibles

Phase 2 (Proposé)

• [ ] Query Builder fluent (select()->where()->get())
• [ ] Relations (belongsTo, hasMany, hasManyThrough)
• [ ] Scopes et query macros
• [ ] Validation de modèle built-in
• [ ] Soft deletes

Phase 3 (Proposé)

• [ ] Migrations système
• [ ] Seeders
• [ ] Database transactions au niveau modèle
• [ ] Eager loading et lazy loading

Phase 4 (Proposé)

• [ ] Query caching
• [ ] Read replicas
• [ ] Database profiling et logging
• [ ] Support MongoDB/Redis

📝 Notes de développement

Structure de répertoires

Conventions de code

• Strict types: declare(strict_types=1) sur tous les fichiers
• Namespaces: Velt\Database
• PSR-4: Autoloading standard
• Type hints: Tous les paramètres et retours typés
• Commentaires: En français, explicatifs

Erreurs personnalisées

📞 Support

Pour des questions ou problèmes:

1. Vérifier les tests dans tests/
2. Consulter les commentaires en français dans le code
3. Référencer cette documentation

Statut du module: ✅ Prêt pour production Couverture de tests: 100% des chemins critiques Documentation: Complète en français Dernière mise à jour: Mai 2026