Blog de Matthieu MEZIL » SQL

Update LINQ To SQL : toutes les colonnes, non pas forcément

Matthieu MEZIL — Sun, 28 Oct 2007 19:05:31 +0000

J’avais blogué sur le fait que le Update de LINQ To SQL se faisait sur toutes les colonnes, y compris celles qui n’ont pas changés, ce qui peut poser des problèmes si vous avez des triggers sur le update de la table SQL.
En réalité, j’avais bloggué un peu vite. En effet, de même qu’il est possible de ne charger des colonnes qu’au moment de l’utilisation de la propriété associée (Delay Loaded = true) avec System.Data.Linq.Link, il est possible de ne pas inclure une colonne à l’update si celle-ci n’a pas été modifiée avec l’attribut UpdateCheck=UpdateCheck.WhenChanged.

Vous pouvez retrouver Delay Loaded et Update Check dans la property grid du designer LINQ To SQL.

Comment récupérer le context depuis un IQueryable

Matthieu MEZIL — Fri, 19 Oct 2007 23:32:20 +0000

Imaginons le cas suivant :
J’ai une instance vers un IQueryable d’entities (exactement un System.Data.Linq.DataQuery) mais je n’ai plus de référence vers le context utilisé pour créer la requête. En parcourant les éléments de mon IQueryable, je peux les modifier. Ensuite, il ma faut appeler la méthode SubmitChanges() sur le context pour que ces modifications soient persistantes en base.
Or, comme je l’ai dit, je n’ai plus de référence sur le contexte.
La seule solution que j’ai trouvé est la suivante : passé par la reflexion pour accéder à un champ privé d’une classe internal au Framework (System.Data.Linq.DataQuery) et récupérer ainsi le DataContext :

var qDb = (DataClasses1DataContext)(q.GetType().GetField("context", BindingFlags.NonPublic | BindingFlags.Instance).GetValue(q));
qDb.SubmitChanges();

Cela marche effectivement avec les Table mais pour les EntitySet, cela est plus compliqué. On peut supposait que T est un Table et par conséquent, récupérer le context par reflexion mais la seule contrainte sur T est que ce soit une classe :

public sealed class EntitySet : IList, ICollection, IList, ICollection, IEnumerable, IEnumerable, IListSource, IEntitySet where TEntity: class

Donc en gros, ne perdez pas de référence sur un DataContext si vous gardez une référence vers une query.

OnValidate

Matthieu MEZIL — Wed, 24 Oct 2007 22:01:02 +0000

Je viens d’avoir une énorme surprise en regardant de plus près le code généré par le designer de LINQ To SQL.
Dans chaque classe d’entité, il y a une partial method OnValidate. Cependant cette méthode n’est jamais appelée ! En fait si, elle est appelée par la classe ChangeProcessor, dans la méthode ValidateAll… par reflexion !!!

Update de LINQ To SQL : Toutes les colonnes :(

Matthieu MEZIL — Thu, 18 Oct 2007 23:01:31 +0000

J’avais précédemment blogué sur mon regret que le Update du SQLDataAdapter généré par le designer de DataSet faisait un Update sur toutes les colonnes, y compris celles qui n’avaient pas été modifié.
C’est pareil avec LINQ To SQL

Un bug sur LINQ to SQL

Matthieu MEZIL — Sun, 20 May 2007 08:01:18 +0000

Imaginons une base de donnée avec une table Test.
Dans un projet, nous rajoutons un LINQ to SQL File et nous y rajoutons la table Test. Nous voulons que le Insert, Update ou Delete sur cette table passe par une procédure stockée. Pour cela, nous rajoutons la proc stock via Object Relational Designer. Ensuite nous avons la possibilité de choisir si le Insert, Update ou Delete sur notre table se fera de façon « classique » ou via une proc stock. Cependant, même si on choisit la proc stock, avec la VS Orcas Beta 1, il y a un petit bug et c’est l’insert, update ou delete « classique » qui ai effectué. On le voit très bien en affectant un TextWriter à la propriété Log du DataContext. Vivement la beta 2!
En plus, j’ai vu dans la présentation de LINQ au Mix 2007 quelque chose que je n’ai pas réussi à reproduire avec la beta 1 : choisir le type de retour d’une fonction SQL. Actuellement, Object Relational Designer en génère un, même si vous avez déjà le même.

LINQ To SQL avec un Mapping XML

Matthieu MEZIL — Thu, 27 Sep 2007 18:09:47 +0000

Comme j’avais pu le lire sur THB (merci à Kader Yildirim et Mitsu), le mapping de LINQ To SQL peut se faire par un fichier externe XML. Guy Burstein revient sur ce point relativement méconnu.

Test unitaires sur LINQ To SQL

Matthieu MEZIL — Mon, 15 Oct 2007 22:18:28 +0000

Ian Cooper a écrit un excellent article sur le sujet.

SQL Metal : le changement de nom n’impacte pas le code

Matthieu MEZIL — Mon, 15 Oct 2007 02:33:31 +0000

Avant de commencer, rappelons que nous parlons là de VS 2008 Beta 2 et que cela pourra être corrigé dans la version finale.
Imaginons une table Client et une table Facture. Une Facture référence un Client.
Du coup, dans la classe Facture générée par le designer LINQ To SQL (SQL Metal), je me retrouve avec deux propriétés Client et Client1. Client est de type et Client1 est de type .
Imaginons que dans notre code, on utilise Client1. Si, via le designer, on renomme Client1 en ClientEntity, notre code reste à Client1

LINQ To SQL RTM

Matthieu MEZIL — Fri, 12 Oct 2007 07:41:24 +0000

Dinesh Kulkarni vient de poster deux billets relatifs à LINQ To SQL RTM vs Beta 2 et au designer LINQ To SQL (SQLMetal).

Argggggggggg les SQLDataAdapter générés via le designer du DataSet

Matthieu MEZIL — Thu, 11 Oct 2007 07:33:51 +0000

Comme m’avait prévenu Cédric, il faut faire attention à ce que la couche DAL ne fasse pas un Update avec un SET sur toutes les colonnes, y compris celles qui n’ont pas changé (dans ce cas là, il réaffecte la même valeur).
Et c’est le cas du SQLDataAdapter généré via le designer du DataSet.

Du coup, soit je gère moi-même le SQLDataAdapter, soit je dis adieu à mon joli trigger.
Dans ce dernier cas, il va falloir tester la valeur de toutes les colonnes.

Du coup mon trigger ne doit plus se déclencher après le update mais avant. Je ne sais pas ce qu’il en est en SQL Server 2005 mais en tout cas, en SQL Server 2000, je ne peux pas faire BEFORE UPDATE. Du coup, je vais faire un INSTEAD OF.

Mais le problème principal, c’est que c’est nul de tester toutes les colonnes en dur. En effet, si la table change, mon trigger ne fonctionne plus. L’idée est donc de faire des tests dynamiques et là c’est Guillaume qui m’a aidé. (j’aurais bientôt mis à contribution tout le pôle DataManagement )

L’idée est de faire un CURSOR :

DECLARE column_cursor CURSOR FOR
SELECT name
FROM sys.syscolumns
WHERE id=OBJECT_ID('Toto')
AND name <> 'ExportedDate'

Et tester si la valeur est différente pour chacune des colonnes.

Le problème c’est que je ne peux pas faire

WHERE Inserted.@columnName <> Toto.@columnName (trop fort le mailto :)))

Pour cela, je vais utiliser

EXEC sp_executesql @sql,N'@diff INT OUTPUT', @diff OUTPUT

avec @sql la requête en nvarchar.

Si @diff (bit) est vrai alors il me reste plus qu’à faire le UPDATE sur la colonne (le INSTEAD OF ne le fait pas) et renseigner ExportedDate.