Je veux mettre à jour le seul champ d'entité lorsque je connais l'ID d'entité.
est-il possible dans LINQ de SQL sans récupérer une entité complète (avec tous les champs de DataContext, qui est au-dessus de la tête)? Est-il possible de créer et de joindre une entité à DataContext et de marquer le (s) champ (s) exact (s) à synchroniser sur DataContext.submitches (ou quelque chose comme ça)?
Merci d'avance!
3 Réponses :
Vous pouvez toujours créer une instruction T-SQL standard et exécuter cela contre votre magasin de données: avec LINQ-TO-SQL lui-même, vous ne pouvez pas faire cela - c'est une hypothèse de base est que Il fonctionne toujours sur l'objet, l'objet entier, et rien que de l'objet. Si vous devez le faire régulièrement, une solution serait de le compromettre dans un processus stocké et d'ajouter cela stocké Proc à votre contexte de données en tant que méthode que vous pouvez appeler sur le contexte de données.
OMG, c'est une pitié. La situation a-t-elle changé dans EF? Souhaitez-vous personnellement sur des opérateurs T-SQL intégrés ou des procédures stockées intégrées dans le modèle pour de tels cas?
NON - EF a la même approche - mais non, NHibernate ou l'un des autres ou des mappeurs. Ils sont conçus pour charger, manipuler et enregistrer objets dans son ensemble. Je ne suis au courant d'aucun orj qui vous permettrait de récupérer un ou deux champs, de changer et de sauver ces ....
Dans EF, nous pouvons créer une entité en mémoire, initier l'entité d'entité de propriété + propriété principale, puis joindre, puis modifier les propriétés que nous souhaitons mettre à jour. SAVECHANGES fonctionne pour les mises à jour.
Vous pouvez rafraîchir l'objet. Cet exemple changera le prénom de la personne:
Merci @gnome. Mais est-il possible de mettre à jour le champ sans que l'entité récupère?
;-) Je ne faisais que re-lire votre message. Autant que je sache, vous aurez besoin de l'entité. Mais cette solution évite cette vieille école-SQL.
Oui, cela évite la SQL "Old-School" - mais il aura besoin de récupérer la totalité de l'entité en premier et sauvera à nouveau la pleine entité. La "vieille école" SQL peut se déplacer très facilement .....
Oui, vous pouvez:
Foo foo=new Foo { FooId=fooId, Modified=... };
// Modified needs to be set to UpdateCheck="Always" in the dbml
Ça a l'air intéressant. Je vais essayer dans quelques jours!
Ah oui, une approche similaire fonctionne dans EF. Bien que je doive générer des propriétés d'entité et une valeur pour la propriété principale.