Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
En 2005, Robert Simpson a créé System.Data.SQLite, un fournisseur SQLite pour ADO.NET 2.0. En 2010, l’équipe SQLite a repris la maintenance et le développement du projet. Il est également important de noter que l’équipe Mono a dépliqué le code en 2007 en tant que Mono.Data.Sqlite. System.Data.SQLite a une longue histoire et a évolué en un fournisseur de ADO.NET stable et complet complet avec les outils Visual Studio. Les nouvelles versions continuent d’expédier des assemblys compatibles avec chaque version de .NET Framework vers la version 2.0 et même .NET Compact Framework 3.5.
La première version de .NET Core (publiée en 2016) était une implémentation unique, légère, moderne et multiplateforme de .NET. Les API et API obsolètes avec des alternatives plus modernes ont été supprimées intentionnellement. ADO.NET n’incluait aucune des API DataSet (notamment DataTable et DataAdapter).
L’équipe Entity Framework était un peu familiarisée avec le codebase System.Data.SQLite. Brice Lambson, ancien membre de l’équipe EF, avait précédemment aidé l’équipe SQLite à ajouter la prise en charge des versions 5 et 6 d’Entity Framework. Brice expérimentait également sa propre implémentation d’un fournisseur SQLite ADO.NET au même moment que .NET Core était planifié. Après une longue discussion, l’équipe Entity Framework a décidé de créer Microsoft.Data.Sqlite en fonction du prototype de Brice. Cela leur permettrait de créer une implémentation légère et moderne qui s’alignerait sur les objectifs de .NET Core.
Comme exemple de ce que nous entendons par plus moderne, voici le code permettant de créer une fonction définie par l’utilisateur dans System.Data.SQLite et Microsoft.Data.Sqlite.
// System.Data.SQLite
connection.BindFunction(
new SQLiteFunctionAttribute("ceiling", 1, FunctionType.Scalar),
(Func<object[], object>)((object[] args) => Math.Ceiling((double)((object[])args[1])[0])),
null);
// Microsoft.Data.Sqlite
connection.CreateFunction(
"ceiling",
(double arg) => Math.Ceiling(arg));
En 2017, .NET Core 2.0 a connu un changement de stratégie. Il a été décidé que la compatibilité avec .NET Framework était essentielle au succès de .NET Core. De nombreuses API supprimées, y compris les API DataSet, ont été ajoutées. Comme cela a été le cas pour de nombreux autres, le déblocage de System.Data.SQLite a permis également son portage vers .NET Core. L’objectif d’origine de Microsoft.Data.Sqlite d’être léger et moderne, cependant, reste toujours. Consultez ADO.NET limitations pour plus d’informations sur les API ADO.NET non implémentées par Microsoft.Data.Sqlite.
Lorsque de nouvelles fonctionnalités sont ajoutées à Microsoft.Data.Sqlite, la conception de System.Data.SQLite est prise en compte. Nous essayons, si possible, de réduire les changements entre les deux pour faciliter la transition entre eux.
Types de données
La plus grande différence entre Microsoft.Data.Sqlite et System.Data.SQLite est la façon dont les types de données sont gérés. Comme décrit dans types de données, Microsoft.Data.Sqlite n’essaie pas de masquer la bizarrerie sous-jacente de SQLite, ce qui permet à toute chaîne arbitraire d’être spécifiée comme type de colonne et n’a que quatre types primitifs : INTEGER, REAL, TEXT et BLOB.
System.Data.SQLite applique une sémantique supplémentaire aux types de colonnes les mappant directement aux types .NET. Cela donne au fournisseur une apparence de typage plus strict, mais il y a des imperfections. Par exemple, ils devaient introduire une nouvelle instruction SQL (TYPES) pour spécifier les types de colonnes d’expressions dans les instructions SELECT.
Chaînes de connexion
Microsoft.Data.Sqlite a beaucoup moins de mots-clés de chaîne de connexion. Le tableau suivant présente les alternatives qui peuvent être utilisées à la place.
| Mot-clé | Alternatif |
|---|---|
| Taille du cache | Envoyer PRAGMA cache_size = <pages> |
| FailIfMissing | Utiliser Mode=ReadWrite |
| FullUri | Utiliser le mot clé de la source de données |
| Mode Journalisation | Envoyer PRAGMA journal_mode = <mode> |
| Format hérité | Envoyer PRAGMA legacy_file_format = 1 |
| Nombre maximal de pages | Envoyer PRAGMA max_page_count = <pages> |
| Taille de page | Envoyer PRAGMA page_size = <bytes> |
| Lecture seule | Utiliser Mode=ReadOnly |
| Synchrone | Envoyer PRAGMA synchronous = <mode> |
| URI | Utiliser le mot clé de la source de données |
| UseUTF16Encoding | Envoyer PRAGMA encoding = 'UTF-16' |
Autorisation
Microsoft.Data.Sqlite n’a aucune API qui expose le rappel d’autorisation de SQLite. Utilisez le problème #13835 pour fournir des commentaires sur cette fonctionnalité.
Notifications de modification de données
Microsoft.Data.Sqlite n’a aucune API qui expose les notifications de modification de données de SQLite. Utilisez le problème #13827 pour fournir des commentaires sur cette fonctionnalité.
Modules de table virtuelle
Microsoft.Data.Sqlite n’a aucune API pour la création de modules de table virtuelle. Utilisez le problème #13823 pour fournir des commentaires sur cette fonctionnalité.
Voir aussi
- types de données
- Chaînes de connexion
- Chiffrement
- Limitations ADO.NET
- Les limitations de Dapper