Forum |  HardWare.fr | News | Articles | PC | Prix | S'identifier | S'inscrire | Aide | Shop Recherche
1683 connectés 

 



 Mot :   Pseudo :  
  Aller à la page :
 
 Page :   1  2  3  4  5  ..  62  63  64  65  66  67
Page Suivante
Auteur Sujet :

[Topic unique] .Net @ Prog

n°2360972
Implosion ​du Sord
Fesseur de chameaux
Posté le 31-08-2020 à 11:32:58  profilanswer
 

Reprise du message précédent :

Yor_le_Bourrin a écrit :

1er point : ça ressemble à un pb de parallélisme : ton repository doit appeler dans 2 méthodes différentes le contexte, qui est partagé. Essaie avec un lock pour voir. Perso j'utilise Mediatr, ça évite ce souci.


Je continue d'investiguer. Faut que je voie comment activer les logs verbeux pour EF, ça devrait peut-être m'aiguiller ?
 

Yor_le_Bourrin a écrit :

2° point : pas de souci de mon côté, mais je suis sous EF 3.1. Visiblement un bug existe en 3.0, je ne sais pas si c'est ton cas. A voir aussi le type de ton TPrimaryKey en pratique.


Dans l'un de mes cas de crash, IEnumerable<TPrimaryKey> est un tableau de string (System.String[])
Je suis avec EF Core 3.1.7, le bug ne devrait plus exister. Il faudrait que je reproduise le cas dans un POC pour le soumettre je pense...
 
 
EDIT : texte edité -> c'est IEnumerable<T> qui est un tableau de string et non T qui est un tableau de string

Message cité 1 fois
Message édité par Implosion du Sord le 31-08-2020 à 15:13:07

---------------
Away from keyboard, close to your breast
mood
Publicité
Posté le 31-08-2020 à 11:32:58  profilanswer
 

n°2360975
Yor_le_Bou​rrin
Posté le 31-08-2020 à 11:46:41  profilanswer
 

Implosion du Sord a écrit :


Je continue d'investiguer. Faut que je voie comment activer les logs verbeux pour EF, ça devrait peut-être m'aiguiller ?


Perso j'encadrerais déjà de logs les requêtes avant d'activer les logs d'EF. Tu verras déjà l'enchainement et pourras confirmer si c'est deux appels en //. Après je dois avouer que je ne sais pas si les logs EF sont verbeux, peut-être que ça reste lisible ?
 
 

Implosion du Sord a écrit :


Dans l'un de mes cas de carsh, <TPrimaryKey> est un tableau de string
Je suis avec EF Core 3.1.7, le bug ne devrait plus exister. Il faudrait que je reproduise le cas dans un POC pour le soumettre je pense...


Avec le string[] je vois mal comment ça pourrait être traduit en SQL, pour moi c'est juste pas supporté. Si tu as un int / Guid pour TPrimaryKey et toujours le problème, là ça sera un bug du framework effectivement.

n°2360988
Implosion ​du Sord
Fesseur de chameaux
Posté le 31-08-2020 à 14:24:53  profilanswer
 

Yor_le_Bourrin a écrit :


Perso j'encadrerais déjà de logs les requêtes avant d'activer les logs d'EF. Tu verras déjà l'enchainement et pourras confirmer si c'est deux appels en //. Après je dois avouer que je ne sais pas si les logs EF sont verbeux, peut-être que ça reste lisible ?


C'est ce que j'aimerai éviter vu la taille de l'app  :sweat: mais j'ai peur de ne pas pouvoir y échapper
 

Yor_le_Bourrin a écrit :


Avec le string[] je vois mal comment ça pourrait être traduit en SQL, pour moi c'est juste pas supporté. Si tu as un int / Guid pour TPrimaryKey et toujours le problème, là ça sera un bug du framework effectivement.


ça se traduit simplement par :

Code :
  1. SELECT column_name(s)
  2. FROM table_name
  3. WHERE column_name IN ('value1', 'value2', ...);


---------------
Away from keyboard, close to your breast
n°2360990
Yor_le_Bou​rrin
Posté le 31-08-2020 à 14:41:31  profilanswer
 

Implosion du Sord a écrit :


ça se traduit simplement par :

Code :
  1. SELECT column_name(s)
  2. FROM table_name
  3. WHERE column_name IN ('value1', 'value2', ...);



 
Non, là column_name est un VARCHAR, donc TPrimaryKey est dans ce cas un string, ce qui est en effet simple. Si TPrimaryKey est un string[], ça devient impossible. Pour simplifier : GetByIdAsync(IEnumerable<string> ids) est OK pour la translation de requête, GetByIdAsync(IEnumerable<string[]> ids) ne l'est pas


Message édité par Yor_le_Bourrin le 31-08-2020 à 14:42:05
n°2360992
Implosion ​du Sord
Fesseur de chameaux
Posté le 31-08-2020 à 15:10:54  profilanswer
 

heu... oui, non, oui... je suis tout à fait d'accord avec toi mais en fait j'ai dit un bêtise   [:kapukapu]  
Ce n'est pas TPrimaryKey qui est de type System.String[] mais bien IEnumerable<TPrimaryKey> ids


---------------
Away from keyboard, close to your breast
n°2360995
Yor_le_Bou​rrin
Posté le 31-08-2020 à 15:39:15  profilanswer
 

Ca commence à être tendu donc. Dernière hypothèse TEntity.id est bien un string aussi dans ce cas ? Dans le cas contraire, possible que le cast ne soit pas géré. Genre string[].Contains(string) se traduit, string[].Contains(object) non

n°2360996
Implosion ​du Sord
Fesseur de chameaux
Posté le 31-08-2020 à 16:05:43  profilanswer
 

J'y ai pensé mais le champs Id de mon entité est bien un string quand j'observe les objets

 

Pour le moment j'ai contourné le problème en faisant ça :

Code :
  1. var r = await _dbSet.ToListAsync();
  2. List<TEntity> objects = r.Where(a => ids.Contains(a.Id)).ToList();
  3. return objects;


Je récupère tous mes objets qui sont en base, puis filtre dans mon backend
En temps normal, si je voie quelqu'un faire ça je le lapide...   [:antp]
Heureusement que le jeu de données n'est pas ouf en taille même dans le cas le plus défavorable (car on est bien dans un code ultra générique ici, un "BaseRepository" )

 


(en tous cas merci Taiche et Yor_le_Bourrin pour votre aide)


Message édité par Implosion du Sord le 31-08-2020 à 16:15:57

---------------
Away from keyboard, close to your breast
n°2361121
TotalRecal​l
Posté le 02-09-2020 à 08:07:09  profilanswer
 

Pour le 2e souci tu peux confirmer que :

Code :
  1. public virtual async Task<IDictionary<TPrimaryKey, TEntity>> GetByIdAsync(IEnumerable<TPrimaryKey> ids)
  2.     {
  3.       var bidules = ids.Take(10).ToList<string>();
  4.       var objects = await _dbContext.Set<TEntity>().Where(r => bidules.Contains(r.id)).ToListAsync()
  5.       return objects.ToDictionary(x => x.Id);
  6.     }


Plante exactement pareil ?
Juste pour être sûr que l'IEnumerable ids est évalué avant la conversion LINQ to SQL, et avec un nombre d'élément et un type acceptables.


Message édité par TotalRecall le 02-09-2020 à 08:12:18

---------------
Réalisation amplis classe D / T      Topic .Net - C# @ Prog
n°2361146
Implosion ​du Sord
Fesseur de chameaux
Posté le 02-09-2020 à 10:10:45  profilanswer
 

Le soucis reste identique.
En général je n'ai qu'un seul élément dans ma liste, donc le volume n'est pas un soucis  [:tinostar]  
 
Notons que je ne peux pas tester strictement ce que tu demandes car TPrimaryKey n'est pas forcément un string (il y a des cas où c'est un entier, d'autres des Guid) et donc .ToList<string> refuse de compiler.
J'ai donc fait un truc comme ça :
 

Code :
  1. public virtual async Task<IDictionary<TPrimaryKey, TEntity>> GetByIdAsync(IEnumerable<TPrimaryKey> ids)
  2.         {
  3.           var bidules = (ids.Take(10) as IEnumerable<string> ).ToList<string>();
  4.           var objects = await _dbContext.Set<TEntity>().Where(r => bidules.Contains(r.id as string)).ToListAsync()
  5.           return objects.ToDictionary(x => x.Id);
  6.         }


 
J'avais testé en injectant une List<string> statique aussi. Même soucis
 
Vu que pour le moment j'ai une solution de contournement et que le jeu de données est petit, je vais attendre le retour d'un gars dans l'équipe et lui refiler le truc.
J'aime pas EF :o


---------------
Away from keyboard, close to your breast
n°2361149
ixemul
Nan mais sans blague ! ⚡
Posté le 02-09-2020 à 10:15:24  profilanswer
 

C'est quand je vois des trucs comme ça que je suis bien content de faire du SQL à la main et du mapping avec Dapper :D


---------------
VA APPRENDRE ET REVIENS QUAND TU SAIS, SINON ABSTIENT TOI C'EST UN GRAND CONSEIL QUE JE TE DONNE... TU ES INCOMPÉTENT ET C'EST UNE RÉALITÉ, TU N'AS RIEN A FAIRE ICI FAUT S'Y CONNAITRE ... -Jojo1998 - RIP - http://tinyurl.com/qc47ftk
mood
Publicité
Posté le 02-09-2020 à 10:15:24  profilanswer
 

n°2361156
Implosion ​du Sord
Fesseur de chameaux
Posté le 02-09-2020 à 10:45:42  profilanswer
 

ixemul a écrit :

C'est quand je vois des trucs comme ça que je suis bien content de faire du SQL à la main et du mapping avec Dapper :D


+1000
Mais je ne peux pas nier que sur de petites applications, les ORM comme EF ou NH peuvent grandement accélérer le travail (tant que l'on tombe pas sur un truc chelou comme mon cas...)


---------------
Away from keyboard, close to your breast
n°2361157
Yor_le_Bou​rrin
Posté le 02-09-2020 à 10:47:59  profilanswer
 

Houla si même à ce niveau ça plante, ça va être tendu. Je ne vois plus que :
- Ticket MS
- Sinon surcharger le générateur de requête pour qu'il prenne en charge ton Contains : https://docs.microsoft.com/en-us/ef [...] operations
 
J'avais déjà fait ça en EF6 pour intégrer des commandes FULL TEXT, mais ils ont enfin ajouté les DbCommandInterceptor en EF Core 3

n°2361242
BilupBaloo
Posté le 03-09-2020 à 10:23:26  profilanswer
 

Comme ça, moi je ne vois qu'un pb de cast que EF n'arrive pas à faire.
 
Ça plante sur tous les types ? Pour toutes les requêtes ?

n°2361248
Yor_le_Bou​rrin
Posté le 03-09-2020 à 11:27:50  profilanswer
 

Avec la dernière version ça n'est plus ambigu :
var bidules = (ids.Take(10) as IEnumerable<string> ).ToList<string>();
var objects = await _dbContext.Set<TEntity>().Where(r => bidules.Contains(r.id as string)).ToListAsync()
 
Là le constructeur de requête n'a plus d'excuse pour confondre la méthode...

n°2361251
BilupBaloo
Posté le 03-09-2020 à 12:06:23  profilanswer
 

ça n'est plus ambigu pour la liste mais le cast du champ est peut-être en cause (r.id as string) ?
 
Est-ce que cela fonctionne en spécifiant explicitement une TEntity ?

n°2361265
Implosion ​du Sord
Fesseur de chameaux
Posté le 03-09-2020 à 13:50:16  profilanswer
 

BilupBaloo a écrit :

ça n'est plus ambigu pour la liste mais le cast du champ est peut-être en cause (r.id as string) ?
 
Est-ce que cela fonctionne en spécifiant explicitement une TEntity ?


 
En remplaçant (r.id as string) par  (r.id.ToString()) le problème reste le même.
Le soucis doit être autour de ce cast pourtant... mais bon pour le moment je vais laisser mon évaluation client-side et attendre le retour d'un gars qui maitrise bien EF pour reprendre le sujet


---------------
Away from keyboard, close to your breast
n°2361277
Yor_le_Bou​rrin
Posté le 03-09-2020 à 14:15:14  profilanswer
 

Pas sûr que ToString soit supporté en EF Core, ni même le cast en fait. J'aurais tendance à faire "var idString = r.id as string;" avant, pour être sûr des types en effet.
 
C'est un peu pénible cette migration EF Core, pas mal d'acquis d'EF6 ont été perdus apparemment.

n°2361393
Implosion ​du Sord
Fesseur de chameaux
Posté le 04-09-2020 à 11:45:13  profilanswer
 

Yor_le_Bourrin a écrit :

Pas sûr que ToString soit supporté en EF Core, ni même le cast en fait. J'aurais tendance à faire "var idString = r.id as string;" avant, pour être sûr des types en effet.


ça n'apportera rien je pense puisque r.id est évalué côté serveur :/
mais je trouve ouf qu'un cast ne soit pas traduit... on bosse sur du SQL Server quand même derrière, c'est pas non plus exotique :o
 

Yor_le_Bourrin a écrit :

C'est un peu pénible cette migration EF Core, pas mal d'acquis d'EF6 ont été perdus apparemment.


vive Dapper !


---------------
Away from keyboard, close to your breast
mood
Publicité
Posté le   profilanswer
 

 Page :   1  2  3  4  5  ..  62  63  64  65  66  67
Page Suivante

Aller à :
Ajouter une réponse
 

Sujets relatifs
service web REST en VB.NET HeySpreadRequete Access avec paramètres, éxécutée en VB .Net
impersonalisation sous ASP.NET[Topic Unique] les blagues pourries de harko et florentg
Generation d'un GIF en ASP.NETAppeler un service web .NET sécurisé en Java
Prog Visual Basic "periodicité"[Oracle] Temps d'execution de requete tres long par rapport au .NET
[VB.NET] Lister des imprimantes réseauxFusion de résultats de requêtes dans une unique Table
Plus de sujets relatifs à : [Topic unique] .Net @ Prog


Copyright © 1997-2018 Hardware.fr SARL (Signaler un contenu illicite) / Groupe LDLC / Shop HFR