Pourquoi Linq tente de vérifier la deuxième expression de toute façon?
.Where(t => String.IsNullOrEmpty(someNullString) || t.SomeProperty >= Convert.ToDecimal(someNullstring))
4 Réponses :
Je ne peux reproduire aucun problème avec l'évaluation court-circuit ...
Je pense que cela évalue quelque chose comme: court-circuit fonctionne bien ici. Je soupçonne d'autres éléments dans votre énumérable Évaluez la première condition ( fournir un peu plus de code afin que nous puissions analyser cela. string.isnullorempty (Somenullstring) ) à False. Pouvez-vous confirmer cela?
est le Si tel est ainsi, avant que toutes les données puissent être saisies, il doit convertir la linq en SQL et pour le faire, il doit convertir la chaîne .where utilisé sur une table <> ?
dans un décimal . Il n'essaie pas de réellement effectuer les comparaisons, il tente de construire les constructions nécessaires à la récupération de données.
Avez-vous une variable Avez-vous essayé avec des parenthèses comme ceci: p> .Where(t => (String.IsNullOrEmpty(someNullString) ||
t.SomeProperty >= Convert.ToDecimal(someNullstring)))
Le => définit la portée de t.
Il y a une solution de contournement sur the || (ou) l'opérateur de Linq avec C # selon lequel vous feriez dans votre cas quelque chose comme: Bien sûr, cela pourrait ne pas être la solution dont vous avez besoin dans votre cas particulier, Mais au moins cela donne une idée de savoir comment contourner l'erreur.
Je trouve soudainement le => et> = dans ce code très déroutant. :-) (et j'ai utilisé les deux assez souvent, mais jamais ensemble dans la même déclaration.)
Oui. Eh bien, merci, je l'ai eu :)
Êtes-vous sûr que cela ne fonctionne pas? Je l'ai testé sur une liste (Linq aux objets) et semble fonctionner.
Lisez la question à nouveau. Bien sûr, cela fonctionne mais il évalue également la deuxième condition tout en utilisant || aurait dû éviter cela ...