fakesnow

fakesnow est un outil permettant d'exécuter, simuler et tester des bases de données Snowflake factices en local. Il propose deux approches : le patching en cours de processus du connecteur Snowflake pour Python, ou un serveur HTTP autonome utilisable par des connecteurs de n'importe quel langage. Patching en cours de processus (Python) : installez avec pip, puis exécutez un script via `fakesnow script.py` ou un module tel que pytest via `fakesnow -m pytest`. Vous pouvez également utiliser `fakesnow.patch()` comme gestionnaire de contexte dans le code. Les imports standards de `snowflake.connector.connect` et `snowflake.connector.pandas_tools.write_pandas` sont patchés automatiquement ; les modules utilisant la syntaxe `from ... import` doivent être nommés explicitement, par exemple `fakesnow.patch("mymodule.write_pandas")`. Le patching s'applique uniquement au processus courant, donc les sous-processus et les clients non-Python nécessitent le serveur. Les bases de données sont en mémoire par défaut et peuvent être persistées en passant un `db_path`. Mode serveur : exécutez `fakesnow -s` (ou via uvx/docker, le conteneur écoutant sur le port 64616) pour démarrer un serveur HTTP. Il peut également être démarré dans un programme Python avec `fakesnow.server()`, qui renvoie les paramètres de connexion et arrête le serveur à la sortie. Le port et la persistance/isolation de la base de données sont configurables via des paramètres de session tels que `FAKESNOW_DB_PATH` (y compris la valeur `:isolated:`). Toute combinaison nom d'utilisateur/mot de passe/compte est acceptée ; le README documente la connexion depuis la CLI Snowflake (config.toml avec `protocol = http`), depuis Java via snowflake-jdbc (avec des notes sur le maintien de `account` dans l'URL et les options JVM `--add-opens` pour Arrow), et via Testcontainers. Des fixtures pytest sont fournies via `pytest_plugins = "fakesnow.fixtures"`, incluant une fixture de session et une fixture `fakesnow_server` qui fournit les paramètres de connexion. Couverture : les éléments entièrement pris en charge incluent les opérations SQL standard et les curseurs, les requêtes sur le schéma d'information, plusieurs bases de données, la liaison de paramètres, les commentaires de table, l'intégration pandas incluant write_pandas, la récupération de lots de résultats via get_result_batches, et le serveur HTTP pour les connecteurs non-Python. Partiellement pris en charge : les fonctions de date, les fonctions d'expressions régulières, les opérations sur données semi-structurées, les tags, la gestion des utilisateurs, les stages et PUT, les formats de fichiers nommés, et COPY INTO depuis des sources S3 et des stages. Pas encore implémenté : le contrôle d'accès et les procédures stockées. Le README note que l'ordre des lignes est non déterministe sauf si ORDER BY est entièrement spécifié, et que le dialecte SQL pris en charge est plus permissif que le vrai Snowflake, donc certaines requêtes peuvent fonctionner en local mais pas contre une instance réelle. COPY INTO peut utiliser la chaîne d'identifiants AWS standard ou une instruction duckdb CREATE SECRET pour des identifiants S3 alternatifs.