mardi, juin 24 2008
LINQ to SQL (detach / re attach dans un modèle N-tiers)
Par Thierry THOUA le mardi, juin 24 2008, 21:54
Lorsque l'on commence à réellement utiliser Linq to SQL, on en arrive vite à se prendre la tête sur certaines parties. Je vais vous présenter ici la problématique d'update d'un objet récupéré via différents DataContext. En effet, il n'est pas simple de faire fonctionner LINQ to SQL avec une instance de DataContext différente pour le "GET" et l' "UPDATE".
lundi, avril 7 2008
Npgsql2 Beta3 est sorti !!!
Par Thierry THOUA le lundi, avril 7 2008, 22:35
Npgsql2 Beta3 est sorti et support à présent (toujours en bêta) Entity Framework pour Postgresql. Il s'agit là de la première version ... Je vous invite donc à le tester et ainsi contribuer à améliorer la qualité de ce driver ;-). Voici le lien.
mercredi, mars 19 2008
LINQ to SQL (locking)
Par Thierry THOUA le mercredi, mars 19 2008, 22:05
Il y a quelques jours, j'ai testé la gestion du "lock" sous Linq to SQL en cas de modification de tuple pendant la manipulation de l'objet chargé. J'avais rédigé un mini commentaire ici. Après avoir vu la remarque de Steve, j'ai décidé d'aller plus loin dans LINQ to SQL et sa gestion du lock. Après avoir réutilisé mon exemple, voici quelques remarques.
L'autre possibilité est le "pessimistic locking" (désolé ... je ne connais pas le terme en français ;-). Il est possible de bloquer un tuple le temps d'une modification. Ceci ne m'a jamais semblé une bonne idée ... Cela ajoute un lag voir des problèmes d'accès en cas de plantage etc. Mais il est intéressant d'avoir connaissance de l'existence de cette possibilité dans LINQ to SQL.
Par défaut, lors d'une mise à jour d'un tuple, Linq2SQL va utiliser tous les champs dans sa clause WHERE. Il est cependant possible de modifier ce comportement via un paramètre "UpdateCheck" nommé de l'attribut ColumnAttribute qui se place au dessus des propriétés ... Ce paramètre accepte un enum qui a trois valeurs.
- Never => La propriété n'entre jamais en ligne de compte.
- Allways => (valeur par défaut). La propriété entre toujours en ligne de compte dans un update.
- WhenChanged => La propriété n'est prise en compte que si elle est modifiée.
L'autre possibilité est le "pessimistic locking" (désolé ... je ne connais pas le terme en français ;-). Il est possible de bloquer un tuple le temps d'une modification. Ceci ne m'a jamais semblé une bonne idée ... Cela ajoute un lag voir des problèmes d'accès en cas de plantage etc. Mais il est intéressant d'avoir connaissance de l'existence de cette possibilité dans LINQ to SQL.
lundi, mars 17 2008
Accès/modification de tuples en // sous Linq to SQL (lock ?)
Par Thierry THOUA le lundi, mars 17 2008, 21:06
Aujourd'hui, je me suis demandé comment fonctionnait le lock des entités sous LINQ to SQL. Sous NHibernate, il existe des mécanismes de lock via un champ timestamp/version dans la table ... Mais qu'en est-il sous LINQ to SQL ... Simple ... clair ... net ... Par défaut tout est géré nativement et une exception se lance en cas de modification d'un tuple qui a été modifié par un autre DataContext ou via la base de données ...
jeudi, février 21 2008
Log des requêtes SQL effectuées par DLINQ
Par Thierry THOUA le jeudi, février 21 2008, 21:52
Il est parfois intéressant de pouvoir tracer les requêtes SQL générées par n'importe quelle bibliothèque afin de pouvoir optimiser certaines choses mais comment le faire sous LINQ ? Voici la réponse ... Il suffit d'utiliser un TextWriter et de positionner la propriété Log de l'objet DataContext .... Et pour faire simple ... il est tout à fait possible de le faire sortir directement sous la console en sortie en utilisant "Console.Out" qui renvoie un TextWriter 
Pagination sous SQL Server
Par Thierry THOUA le jeudi, février 21 2008, 21:32
Depuis quelques temps, dans le cadre du développement des bibliothèques Lelibre.Fwk, j'étais à la recherche de la solution pour supporter la pagination sous SQL Server ... Après, quelques tests et autres demandes, j'ai trouvé la solution ^_^. Je vous la donne. J'ai par après eu l'idée de valider ou améliorer celle-ci en regardant ce qu'executait LINQ lorsque je demandais une "requête" ....
[csharp] var q = (from c in dataContext.Blog select c).Skip(5).Take(10);Et voici le code SQL généré:
SELECT [t1].[BlogID], [t1].[Title]
FROM (
SELECT ROW_NUMBER() OVER
(ORDER BY [t0].[BlogID], [t0].[Title]) AS [ROW_NUMBER], [t0].[BlogID], [t0].[Title]
FROM [Blogs] AS [t0]
) AS [t1]
WHERE [t1].[ROW_NUMBER] BETWEEN @p0 + 1 AND @p0 + @p1
ORDER BY [t1].[ROW_NUMBER]
En SQL simple, on aurait également pu effectuer un query du type:
SELECT TOP 10 * FROM (SELECT ROW_NUMBER() OVER (ORDER BY BlogID, Title) AS RowNumber, * FROM Blogs WHERE RowNumber > 5Cependant, je reste d'avis qu'il aurait été plus sympathique de pouvoir utiliser LIMIT / OFFSET ;-).
jeudi, octobre 18 2007
DLinq 1..N, la base des relations + select
Par Thierry THOUA le jeudi, octobre 18 2007, 18:40
Comme expliqué dans un des mes précédents post, il y a une nouvelle technologie qui sortira en .NET 3.5. Ainsi, je me suis décidé à réaliser un mini exemple en SQL Server pour un peu expliquer comment fonctionne la base des select en LINQ.
dimanche, septembre 23 2007
DLinq, c'est magique ?
Par Thierry THOUA le dimanche, septembre 23 2007, 00:58
Etant sur un nouveau projet associatif, je me suis tourné depuis quelques semaines dans la découverte et l'utilisation de DLINQ. D'entrée, j'ai été confronté à un problème que je juge de taille... En effet, DLinq ne supporte actuellement que SQL Server (et déclinaison Express) ainsi que Access (que je n'ai pas réussi à faire fonctionner ...). La question qui me vient directement à l'esprit ... Et les autres ??? On fait quoi ??? ... Heureusement qu'il existe un petit projet en développement qui fournit un connecteur pour MySQL, Oracle et PostgreSQL. Et heureusement que je partais d'un existant nul .... ;-). J'espère que Mr Microsoft implémenera ces classes pour d'autres SGBD.