mardi, juin 24 2008

LINQ to SQL (detach / re attach dans un modèle N-tiers)

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".

Lire la suite...

lundi, avril 7 2008

Npgsql2 Beta3 est sorti !!!

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)

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.

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.

  1. Never => La propriété n'entre jamais en ligne de compte.
  2. Allways => (valeur par défaut). La propriété entre toujours en ligne de compte dans un update.
  3. WhenChanged => La propriété n'est prise en compte que si elle est modifiée.
Cela offre une grande souplesse, il est donc possible de faire un lock sur un champ d'une table .. par exemple un timestamp ... et les autres champs prendront "never".


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 ?)

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

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

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 > 5
Cependant, 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

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.

Lire la suite...

dimanche, septembre 23 2007

DLinq, c'est magique ?

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.

Lire la suite...

Page top