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.
5 réactions
1 De Steve Degosserie - 20/03/2008, 09:42
Salut Titi,
Le fait de devoir mettre un attribut [ColumnAttribute] est assez 'invasif' dans ton modèle ... c'est flexible au niveau des fonctionnalités, mais pas au niveau de l'implémentation. Je t'invite à lire cet article qui évalue les possibilités de Linq to SQL par rapport à la 'Persistence Ignorance' (concept très important dans une architecture de type DDD):
iancooper.spaces.live.com...
Aussi, j'ai découvert une propriété 'IsVersion' dans le [ColumnAttribute] ... on peut donc aussi faire de l'optimistic locking avec un champ version / timestamp.
Je me mets en mode traducteur ...
lock = verrou
pessimistic locking = verrouillage pessimiste
optimistic locking = verrouillage optimiste
;o)
Concernant le pessimistic locking, je ne serais pas surpris que cela ne soit pas supporté par Linq to SQL. NHibernate le supporte par contre.
Il existe un troisième type de locking, qui est la fondation du DDD ... et que je n'ai pas encore vu appliqué et supporté dans un ORM standard : le Coarsed-Grained Locking :
martinfowler.com/eaaCatal...
J'ai essayé de l'appliquer avec NHibernate mais ça ne marche malheureusement pas comme je le voudrais ...
Si le DDD t'intéresse, je suis en train de réfléchir à la création d'un projet OpenSource pour construire une Software Factory pour le Domain Driven Design (il n'en existe pas vraiment à l'heure actuelle) ... et j'ai de bonnes idées ... :)
(ton Captcha est chiant, il faut trop réfléchir lol)
2 De Thierry Thoua - 20/03/2008, 12:16
Le ColumnAttribute est propre au système utilisé par LINQ to SQL pour le mapping... Dès lors ... certes en DDD ... il y a la possibilité d'avoir des limitations ... Mais aucun modèle n'est parfait et ActiveRecord utilise le même modèle pour déclarer certaines informations ;-). Pour ce qui est du champ nommé "IsVersion", il s'agit en effet d'une colonne dédié au versionning des tuples comme le fait NHibernate via le mapping <version>... J'ai oublié de le signaler ;-). Pour ce qui est du pessimitic ... il le supporte mais évidement comme toujours tu as actuellement les limitations de la base de données ... et le fait que Microsoft ne livre qu'une implémentation de LINQ to SQL pour SQL Server. Ce que je tente de mettre en évidence dans ce type de post est la possibilité de pouvoir développer une réelle application via Linq to SQL. Linq to SQL est très basique.... certes mais il sera suffisant pour plusieurs projets. Après avant de comparer NHibernate avec Linq , je pense qu'il faut attendre la sortie de Entity Framework qui lui est un réel ORM.
Pour ton projet OpenSource, cela m'interesse ;-)....
ps: N'oublie pas de faire un résumé sur ton blog des DSL =D.
3 De Steve Degosserie - 20/03/2008, 13:17
Le problème de Linq to SQL est que c'est un projet mort né. Microsoft a sorti Linq to SQL pour avoir un pied dans le monde des ORM (après leur débâcle avec 'ObjectSpaces'). Leur vrai projet, c'est Entity Framework (qui n'est pas qu'un ORM). Dès qu'il sera sorti, Microsoft ne parlera plus de Linq to SQL, qui est moins puissant, ne supporte qu'SqlServer.
Donc, utiliser Linq To SQL aujourd'hui pour développer de réelles applications, oui, ça marche ... encore heureux, sinon il y aurait de quoi se poser des questions lol
Par contre, je ferais attention de garder le modèle le plus indépendant possible (PI = Persistene Ignorance) de Linq to SQL, ce qui facilitera la migration vers Entity Framework quand cette techno sera prête (Microsoft proposera probablement des wizards de migration mais bon ... mieux vaut prévenir que guérir). Par précaution, je n'utiliserais pas non plus LtS pour de grosses applications critiques, mais uniquement pour de petites applications (front office).
My 2 cents comme on dit ;o)
PS : Elles sont marrantes tes stats sur les browsers et les OS :) plutôt inhabituelles ... j'en connais un qui n'utilise pas bcp Windows à la maison lol
4 De Thierry Thoua - 20/03/2008, 15:51
En effet, Entity Framework n'est pas qu'un ORM mais il se base sur Linq To SQL. Dès lors, il est intéressant de comprendre ce qui est généré en natif. Je pense honnêtement que la grande nouveauté des prochains mois sera ADO.Net Data Services pour les applications distribuées ... et la connaissance de Entity Framework et donc de Linq to SQL sera un plus non négligeable pour optimiser les développements. Après, on utilise toujours des "objets" ... Ceux-ci pourront toujours être généré via un autre ORM ... Après, il y a l'approche "gestion session/transaction" ... Abstraire cette partie serait en effet une bonne idée. Mais est-ce réellement indispensable ? ... Je ne pense pas que l'on change souvent d'orm en plein projet après validation de la structure de celui-ci ;-)
PS: Mes statistiques ne sont pas prises en compte dans les historiques ;-).
5 De Arrangeur - 17/05/2008, 17:47
un petit commentaire oour te dire qu'il est toujours plaiant de surfer sur tn blog ;)