Issue6 #25
Issue6 #25
Conversation
Création des classes TypeEditor et TypeRenderer et modification de la classe AlignmentGUI
Codecov Report
@@ Coverage Diff @@
## master #25 +/- ##
=========================================
- Coverage 20.24% 18.2% -2.04%
=========================================
Files 47 49 +2
Lines 3913 4115 +202
Branches 527 565 +38
=========================================
- Hits 792 749 -43
- Misses 3059 3307 +248
+ Partials 62 59 -3
Continue to review full report at Codecov.
|
|
@tfrancart @LYNCETECH Ca me semble bien, mais attention sur un point: Ce qui veut dire que si on edite validity/type sur un Mapping deja dans un SortedSet, le comportement est incoherent. Il y a un risque certain que l'objet soit introuvable ("contains" échoue), ou qu'on crée un bug mémoire si on édite avec les valeurs qu'un autre objet a déjà dans le SortedSet. Le plus on change d'éléments durant une session, le plus on risque d'avoir des crash mémoire ou des comportements incohérents d'OnAGUI. Solution 1: Solution 2: Solution 3: La solution 1 est la plus restrictive en terme d'alignement (critère d'unicité basé sur les uris uniquement) , la solution 2 risque d'avoir un impact sur les perfs quand on change un type/validité (lag de l'UI si beaucoup d'alignement chargé). La solution 3 peut etre la meilleur comme la pire, il faudrait retirer les méthodes compare/hashcode et voir exactement jusqu'ou ca tire les changements. Vous en pensez quoi? |
Pour les perfs, tu es mieux placé que nous - nous n'avons pas vraiment fait de tests de perfs sur des gros volumes. La solution 2 me semble la moins impactante si tu confirmes mon impression que l'intégralité du tableau est déjà réaffichée à chaque fois. |
|
@tfrancart @LYNCETECH Solution 2 ca me va, on verra si les perfs suivent pas (autrement dit, si changer type/validité freeze l'interface). Oui la table doit se remettre à jour pour chaque ajout (comme elle le fait quand l'import ajoute des mappings). Au pire un refresh a appelé au bon endroit, mais ca devrait pas etre utile. |
…u changement du changement de type et de validity par un remove/add(solution 2)
|
Nous avons fini de mettre en place la solution 2. Nous avons constaté que les commentaires sont aussi éditables, est ce qu'on peut apporter ces changements également sur les commentaires en interdisant le "setComment"?. Qu'en penses tu? |
|
@tfrancart @LYNCETECH Bon, j'ai repris le code avec un peu de recul. Actuellement private T firstConcept = null;
private V secondConcept = null;
private double score = 0.0;
private MAPPING_TYPE type = MAPPING_TYPE.EQUIV;
private String method = UNKNOW_METHOD;
private VALIDITY validity = VALIDITY.TO_CONFIRM;
private String comment = "";
private Map<String, String> meta = new TreeMap<String, String>();
private DateTime creationDate = new DateTime();Question ouverte (oublions OnAGUI): quels sont ceux qui rentrent en compte dans l'unicité? Est-ce qu'on considère que la moindre modification en fait un object différent au sens de l'égalité? Je vois qu'il y a un bug entre "equals" et "compareTo" (i.e. je suis capable de creer deux objets o1 et o2 tel que o1.compareTo(o2) == 0 mais o1.equals(o2) == False, ce qui est incorrect) Si on répond a la question principale du critère d'unicité, alors je peux répondre a la question sur quoi faire du "comment" :) |
|
Le 5 avril 2017 à 18:59, Laurent Mazuel <notifications@github.com> a écrit :
@tfrancart <https://github.com/tfrancart> @LYNCETECH
<https://github.com/LYNCETECH> Bon, j'ai repris le code avec un peu de
recul. Actuellement Mapping a cet ensemble d'attributs:
private T firstConcept = null;
private V secondConcept = null;
private double score = 0.0;
private MAPPING_TYPE type = MAPPING_TYPE.EQUIV;
private String method = UNKNOW_METHOD;
private VALIDITY validity = VALIDITY.TO_CONFIRM;
private String comment = "";
private Map<String, String> meta = new TreeMap<String, String>();
private DateTime creationDate = new DateTime();
Question ouverte (oublions OnAGUI): quels sont ceux qui rentrent en compte
dans l'unicité? Est-ce qu'on considère que la moindre modification en fait
un object différent au sens de l'égalité?
Pour moi :
- firstConcept
- secondConcept
- type
- method
Une même méthode d'alignement ne peut pas produire 2 alignements du même
type entre les 2 mêmes concepts.
Je vois qu'il y a un bug entre "equals" et "compareTo" (i.e. je suis
… capable de creer deux objets o1 et o2 tel que o1.equals(o2) mais
o1.compareTo(o2) != 0, ce qui est incorrect)
Si on répond a la question principale du critère d'unicité, alors je peux
répondre a la question sur quoi faire du "comment" :)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#25 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ACmj8Y99m7coFRww2-qmoO76MUNGqswAks5rs8hqgaJpZM4MuWXL>
.
--
*Thomas Francart* -* SPARNA*
Web de *données* | Architecture de l'*information* | Accès aux
*connaissances*
blog : blog.sparna.fr, site : sparna.fr, linkedin :
fr.linkedin.com/in/thomasfrancart
tel : +33 (0)6.71.11.25.97, skype : francartthomas
|
|
@tfrancart @LYNCETECH je suis perdu là, la feature branch #41 c'était justement par pour cette PR ici? Dans ce cas pourquoi elle s'appelle "Issue 15", et ici "Issue 6"? |
|
J'ai du me mélanger les pinceaux en créant la feature branch. Je vais essayer de refaire la manip. |
|
J'ai créé une nouvelle feature branch : https://github.com/lmazuel/onagui/tree/issue6-feature-branch |
|
Je ferme cette PR puisqu'elle serait mergé a partir de la feature branch. @tfrancart si tu peux résoudre les conflits sur l'autre PR, comme ca la feature branch est crée pour de vrai. |
Pouvoir éditer le type de la correspondance dans le tableau (soit par clic, soit dans le menu clic-droit pour des changements en masse)
Fix #6