vidjil issueshttps://gitlab.inria.fr/vidjil/vidjil/-/issues2020-05-28T12:09:12+02:00https://gitlab.inria.fr/vidjil/vidjil/-/issues/3736FineSegmenter et séquences revcomp ?2020-05-28T12:09:12+02:00Mathieu GiraudFineSegmenter et séquences revcomp ?Le `FineSegmenter` est bien capable de recevoir des séquences dans un sens ou dans l'autre (et cela doit être testé, #2259). Mais le traitement "`reversed` ou pas" me semble finalement assez externe au `FineSegmenter` (notamment avec `se...Le `FineSegmenter` est bien capable de recevoir des séquences dans un sens ou dans l'autre (et cela doit être testé, #2259). Mais le traitement "`reversed` ou pas" me semble finalement assez externe au `FineSegmenter` (notamment avec `sequence_or_rc = revcomp(sequence, reversed);`)...
Peut-être qu'un ~"dev\-refactor" permettrait de séparer cela avec
- un `FineSegmenter` qui ne traite que des séquences dans le bon sens
- un wrapper qui fonctionne pour les deux senshttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3593Moins de json dans Sample/CloneOutput ?2018-10-24T16:25:25+02:00Mathieu GiraudMoins de json dans Sample/CloneOutput ?Prend la suite de #3358.
Voir en particulier https://gitlab.inria.fr/vidjil/vidjil/issues/3358#note_124650 et https://gitlab.inria.fr/vidjil/vidjil/issues/3358#note_124819.Prend la suite de #3358.
Voir en particulier https://gitlab.inria.fr/vidjil/vidjil/issues/3358#note_124650 et https://gitlab.inria.fr/vidjil/vidjil/issues/3358#note_124819.https://gitlab.inria.fr/vidjil/vidjil/-/issues/3437d3.js : conserver, changer ?2019-01-10T15:21:24+01:00Mathieu Giraudd3.js : conserver, changer ?Conservera-t-on a terme d3.js ? Très puissant, mais maitrise-t-on ce qu'il se passe ?
chart.js va être testé par @flothoni pour ~"app\-stats" stats#233, on pourra ainsi se faire une idée.
(Notons que même le ~"client\-grid" pourrait êtr...Conservera-t-on a terme d3.js ? Très puissant, mais maitrise-t-on ce qu'il se passe ?
chart.js va être testé par @flothoni pour ~"app\-stats" stats#233, on pourra ainsi se faire une idée.
(Notons que même le ~"client\-grid" pourrait être fait en chart.js, http://www.chartjs.org/samples/latest/scriptable/bubble.html). Mais chart.js ne permet pas d'export svg.https://gitlab.inria.fr/vidjil/vidjil/-/issues/3360Gestion plus propre des warnings2021-02-03T09:09:32+01:00Mikaël SalsonGestion plus propre des warningsPour l'instant l'ajout d'un warning se fait dans le JSON. Si on veut afficher quelque chose sur la sortie standard c'est géré indépendamment, avec des messages qui peuvent diverger.
Ce n'est donc pas très générique.
De plus l'ajout d'un...Pour l'instant l'ajout d'un warning se fait dans le JSON. Si on veut afficher quelque chose sur la sortie standard c'est géré indépendamment, avec des messages qui peuvent diverger.
Ce n'est donc pas très générique.
De plus l'ajout d'un warning dans le JSON se fait par un code unique, sous forme de chaîne, suivie d'une description.
Plusieurs éléments :
* [ ] Ne pourrait-on pas avoir une constante pour chaque warning (toujours préférable aux chaînes pour lesquelles on risque une typo) ?
* [ ] Le message ne peut-il pas être mis automatiquement (tous définis dans un tableau commun) plutôt que d'avoir à le réécrire à chaque fois ?
* [x] Les warnings ne peuvent-ils pas exister indépendamment du JSON ? Ensuite c'est chaque type de sortie qui définit ce qu'elle fait du warning.https://gitlab.inria.fr/vidjil/vidjil/-/issues/3084germline_id, *.g et vidjil-algo2020-11-19T08:41:57+01:00Mathieu Giraudgermline_id, *.g et vidjil-algoSuite à !158, cela me tenterait presque de déplacer `germline_id` dans `algo/`. En effet, `germline_id` est bien la version des germlines utilisée par l'algo.
En effet `germline/` est autonome, avec ses tests. On peut désormais faire év...Suite à !158, cela me tenterait presque de déplacer `germline_id` dans `algo/`. En effet, `germline_id` est bien la version des germlines utilisée par l'algo.
En effet `germline/` est autonome, avec ses tests. On peut désormais faire évoluer les germlines, travailler sur `split-from-imgt`, faire les tests qui vont avec sans casser l'algo. Quand on est content, on met à jour `germline_id` et on travaille sur l'algo.
Problème : on trouve aussi ces numéros de versions dans les `*.g` (mais qui sont aussi, quelque part, des choses plutôt algo).
Voir #1491.https://gitlab.inria.fr/vidjil/vidjil/-/issues/3064Stats : controlleur 'stats' vs controlleur 'compare patients' vs controlleur ...2018-02-27T14:29:40+01:00Mathieu GiraudStats : controlleur 'stats' vs controlleur 'compare patients' vs controlleur 'set'A-t-on besoin de trois controlleurs différents ?
cc @RyanHerbA-t-on besoin de trois controlleurs différents ?
cc @RyanHerbhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2959Groupe public géré par web2py2018-01-08T09:54:07+01:00Mathieu GiraudGroupe public géré par web2pyNous gérons nous-même le groupe public.
Il y a aussi `everybody_group_id` dans `Auth` (et donc dans `VidjilAuth`), qui apparamment gère aussi `has_permission`. Je ne sais pas si cela vaudrait le coup ou pas de l'utiliser pour ne plus le...Nous gérons nous-même le groupe public.
Il y a aussi `everybody_group_id` dans `Auth` (et donc dans `VidjilAuth`), qui apparamment gère aussi `has_permission`. Je ne sais pas si cela vaudrait le coup ou pas de l'utiliser pour ne plus le faire de notre côté.
cc @RyanHerbhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2747Organiser les sample_sets par projet pour accélérer les requêtes2020-09-23T17:32:47+02:00Ryan HerbertOrganiser les sample_sets par projet pour accélérer les requêtesActuellement on a un système qui est très flexible en termes de permissions et d'associations de samples à plusieurs sets, voire plusieurs groupes. Mais c'est aussi plutôt lent à cause du système de permissions que j'ai créé.
Avec la no...Actuellement on a un système qui est très flexible en termes de permissions et d'associations de samples à plusieurs sets, voire plusieurs groupes. Mais c'est aussi plutôt lent à cause du système de permissions que j'ai créé.
Avec la notion de hierarchie de groupes, on se retrouve avec des requêtes plutôt complexes pour déterminer si l'utilisateur a accès à un élément.
> Il faut chercher si l'utilisateur appartient à un groupe qui a la permission `access` ou à un groupe dont le parent a la permission `access`
Donc lister les sets d'un type particulier auxquels un utilisateur a accès revient au code suivant:
``` python
def vidjil_accessible_query(self, name, table, user_id=None):
"""
Returns a query with all accessible records for user_id or
the current logged in user
this method does not work on GAE because uses JOIN and IN
This is an adaptation of accessible_query that better fits
the current auth system with group associations
:param: name: The name of the query (eg. 'read')
:param: table: The table for accessibility
:param: user_id: ID of the user
Example:
Use as::
db(auth.vidjil_accessible_query('read', db.mytable, 1)).select(db.mytable.ALL)
"""
if not user_id:
user_id = self.user_id
db = self.db
if isinstance(table, str) and table in self.db.tables():
table = self.db[table]
elif isinstance(table, (Set, Query)):
# experimental: build a chained query for all tables
if isinstance(table, Set):
cquery = table.query
else:
cquery = table
tablenames = db._adapter.tables(cquery)
for tablename in tablenames:
cquery &= self.vidjil_accessible_query(name, tablename,
user_id=user_id)
return cquery
if not isinstance(table, str) and\
self.has_permission(name, table, 0, user_id):
return table.id > 0
membership = self.table_membership()
permission = self.table_permission()
perm_groups = self.get_permission_groups(name, user_id)
query = (table.id.belongs(
db(((membership.user_id == user_id) &
(membership.group_id.belongs(perm_groups)) &
(membership.group_id == permission.group_id) &
(permission.name == PermissionEnum.access.value) &
(permission.table_name == table)))._select(permission.record_id)) |
table.id.belongs(
db(((membership.user_id == user_id) &
(membership.group_id.belongs(perm_groups)) &
(membership.group_id == db.group_assoc.second_group_id) &
(db.group_assoc.first_group_id == permission.group_id) &
(permission.name == PermissionEnum.access.value) &
(permission.table_name == table)))._select(permission.record_id)))
if self.settings.everybody_group_id:
query |= table.id.belongs(
db(permission.group_id == self.settings.everybody_group_id)
(permission.name == name)
(permission.table_name == table)
._select(permission.record_id))
return query
```
Ce qui produit la requête SQL suivante:
```sql
SELECT `patient`.`id`, `patient`.`first_name`, `patient`.`last_name`, `patient`.`birth`, `patient`.`info`, `patient`.`id_label`, `patient`.`creator`, `patient`.`sample_set_id` FROM `patient`
WHERE (
(`patient`.`id` IN
(SELECT `auth_permission`.`record_id` FROM `auth_permission`, `auth_membership`
WHERE (
(
(
(
(`auth_membership`.`user_id` = 2)
AND (`auth_membership`.`group_id` IN (4))
)
AND (`auth_membership`.`group_id` = `auth_permission`.`group_id`)
) AND (`auth_permission`.`name` = 'access')
) AND (`auth_permission`.`table_name` = 'patient')
))
)
OR (`patient`.`id` IN
(SELECT `auth_permission`.`record_id` FROM `auth_permission`, `auth_membership`, `group_assoc`
WHERE (
(
(
(
(
(`auth_membership`.`user_id` = 2)
AND (`auth_membership`.`group_id` IN (4))
)
AND (`auth_membership`.`group_id` = `group_assoc`.`second_group_id`)
) AND (`group_assoc`.`first_group_id` = `auth_permission`.`group_id`)
) AND (`auth_permission`.`name` = 'access')
) AND (`auth_permission`.`table_name` = 'patient')
)
)
));
```
On a donc une requête composée de deux sous-requêtes chacune contenant un `IN` aussi long que le nombre de groupes auxquels l'utilisateur appartient, l'une avec un `join` et l'autre avec deux `join` (ici les joins sont implicites).
Et les autres primitives du model `VidjilAuth` sont composées de plusieurs `joins` et souvent plusieurs requêtes.
Avec une organisation par projet (avec une nouvelle table, et une clef étrangère dans la table `sample_set`) on pourrait se débarrasser complètement de la permission `access`, et par la même occasion on laisse tomber cette anbiguïté qu'on a avec les groupes de projets/hôpitaux et les groupes de rôles/permissions.
La requête "patient" deviendrait:
```python
def get_project_sets(type, project_id):
return db(
(db.sample_set.project_id == project_id) &
(db.sample_set.sample_type == type) &
(db[type].sample_set_id == db.sample_set.id)
).select(db[type].*)
```
Avec auparavant avoir vérifié que l'utilisateur ait accès à un groupe/rôle apparetenant au projet (2 joins sur relativement peu de données). Ce qui nous donne un total de 4 joins sur deux requêtes par rapport à un total de 3 joins répartis sur 3 requêtes, et on perd les `IN`
Il y a plusieurs autres endroits où des gains de jointures ou de requêtes seraient aussi envisageables (`get_permission(...)`, `can_view_sample_set(...)`, ...).
Ainsi que des endroits où les requêtes seraient plus complexes ?
J'aurais tendance à vouloir limiter les associations de samples à des sets du même projet car celà simplifierai certaines requêtes, comme l'autocompletiondes tags, et ainsi que celle des samples_sets à l'ajout d'un sample.
Ca éliminerait également l'impacte des grosses requêtes auxquelles nous les admins soumettons la BDD. Et donc on n'occuperait plus un (voire plus) de processus uwsgi pendant des durées prolongées (par exemple, plus d'une minute pour un compare patient).
Cette moification demanderait beaucoup de travail, donc ça ne serait pas pour tout de suite, mais je pense que celà réduirait le nombre de timeouts subis par nos utilisateurs. Celà demanderait peut-être plus d'analyse, de tests et de benchmarks.https://gitlab.inria.fr/vidjil/vidjil/-/issues/2585haml2023-03-01T16:42:41+01:00Mathieu Giraudhaml@RyanHerb a présenté à Douai haml : http://haml.info
Implémentation python ? https://github.com/mikeboers/PyHAML ?@RyanHerb a présenté à Douai haml : http://haml.info
Implémentation python ? https://github.com/mikeboers/PyHAML ?https://gitlab.inria.fr/vidjil/vidjil/-/issues/2438Eviter les initialisations multiples2017-11-14T17:42:00+01:00Ghost UserEviter les initialisations multiplesJe remarque, sans savoir précisément où, que certaines vues sont initialisées plusieurs fois. Par exemple, il y a 3 exécutions de `Builder.init()` à l'ouverture de la page.
C'est sans doute lié à des mécaniques d'`udpate`.
Régler...Je remarque, sans savoir précisément où, que certaines vues sont initialisées plusieurs fois. Par exemple, il y a 3 exécutions de `Builder.init()` à l'ouverture de la page.
C'est sans doute lié à des mécaniques d'`udpate`.
Régler ce souci permettrait certainement de gagner en performance, ou du moins de limiter les appels 'superflus'.Ryan HerbertRyan Herberthttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2201Ne pas avoir de variables globales sur les différentes vues2021-08-10T16:39:43+02:00Mathieu GiraudNe pas avoir de variables globales sur les différentes vuesDiscussion avec @aurelBZH, @mikael-s et @RyanHerb (en partant de #2182 et autres).
On ne devrait pas utiliser de variables globales `sp`, `segment`... pour chaque vue, mais avoir uniquement des appels au modèle.
Les `m.graph` et `m.s...Discussion avec @aurelBZH, @mikael-s et @RyanHerb (en partant de #2182 et autres).
On ne devrait pas utiliser de variables globales `sp`, `segment`... pour chaque vue, mais avoir uniquement des appels au modèle.
Les `m.graph` et `m.sp` ne sont que des hacks temporaires (on pourrait avoir zéro ou plusieurs `sp`, et le code doit fonctionner).
Parmi les pistes évoquées, les vues pourraient s'enregistrer auprès de `shortcut` et `url_obs` (et potentiellement d'autres). Plus généralement, comme les vues s'enregistrent déjà auprès du modèle, une solution pourrait d'avoir des fonctions type `m.getViews(SP)` qui renvoie une *liste* de vues d'un certain type. À réfléchir/discuter encore, pas urgent pour l'instant.
/label ~client ~"!-reflexion" ~"!-hard"
https://gitlab.inria.fr/vidjil/vidjil/-/issues/1559model.js et vues: updateXxx(), découpage judicieux ?2019-11-04T06:50:47+01:00Vidjil Teammodel.js et vues: updateXxx(), découpage judicieux ?La doc devrait mieux expliquer le fonctionnement de `update()` / `updateModel()` / `updateElem()` / `updateElemStyle()` / `updateStyle()` et surtout leur relation entre eux. Je ne sais pas si c'est dans chaque fonction, ou plutôt au débu...La doc devrait mieux expliquer le fonctionnement de `update()` / `updateModel()` / `updateElem()` / `updateElemStyle()` / `updateStyle()` et surtout leur relation entre eux. Je ne sais pas si c'est dans chaque fonction, ou plutôt au début de `model.js`,
J'ai par exemple du mal à comprendre pourquoi `updateModel()` est appelé par certaines fonctions.
@Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/4147Simplifier scatterplot+graph en extrayant des choses indépendantes, pour les ...2020-01-21T17:03:42+01:00Mathieu GiraudSimplifier scatterplot+graph en extrayant des choses indépendantes, pour les paramètresSuggestion de @duez (en parlant de !565)
Voir aussi #2245.Suggestion de @duez (en parlant de !565)
Voir aussi #2245.https://gitlab.inria.fr/vidjil/vidjil/-/issues/4114axes: refactor GermlineAxis, et plus généralement refactor des axes2020-01-22T15:20:37+01:00Mathieu Giraudaxes: refactor GermlineAxis, et plus généralement refactor des axes@duez est en train de travailler@duez est en train de travaillermarc duezmarc duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3184Factoriser js/form_builder.js et views/partial/file/form.html2018-04-17T14:55:19+02:00Mathieu GiraudFactoriser js/form_builder.js et views/partial/file/form.htmlOn peut vivre avec la duplication actuelle même si ce n'est pas très agréable.
Serait-ce possible de faire un appel de `node ...` sur un `.js` qui regénererait `form.html` à partir de `js/form_builder.js` ? Ou une autre solution dans l'...On peut vivre avec la duplication actuelle même si ce n'est pas très agréable.
Serait-ce possible de faire un appel de `node ...` sur un `.js` qui regénererait `form.html` à partir de `js/form_builder.js` ? Ou une autre solution dans l'autre sens ?
Si c'est trop complexe, pas de soucis, on laisse ainsi.
cc @RyanHerbhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2700Réduire les différences entre MODE_BAR et MODE_GRID2018-10-03T23:57:38+02:00Mathieu GiraudRéduire les différences entre MODE_BAR et MODE_GRIDY a-t-il des raisons autres qu'historiques qui fait qu'on a tant de différences/recopies entre les deux modes d'affichage ?
- dans `generic_axis.js`, `computeLabels` et `computeBarLabels` sont bien différents (je m'en suis rendu compt...Y a-t-il des raisons autres qu'historiques qui fait qu'on a tant de différences/recopies entre les deux modes d'affichage ?
- dans `generic_axis.js`, `computeLabels` et `computeBarLabels` sont bien différents (je m'en suis rendu compte en essayant de faire #2699, voir !91)
- dans `scatterplot.js`, similarités de codes entre `computeBarTab` utilise `axisX.posBarLabel
Dans `scatterplot.js`, au moment de faire le bar plot, on doit certes avoir une gestion différenciée de l'axe Y. Mais j'ai l'impression que tout ce qui touche l'axe X devrait être identique/générique (et #2394 serait alors naturel). Que ce soit en `BAR` ou en `GRID`, que ce soit en valeurs génériques ou numériques, on peut avoir (ou pas) des valeurs `?`, on a envie d'avoir du `nice_{floor,ceil}` #2699, on peut vouloir (ou pas) zoomer #2431.
cc @RyanHerbWeb 2018.01https://gitlab.inria.fr/vidjil/vidjil/-/issues/5031germlines/ et python32024-01-31T18:10:53+01:00Mathieu Giraudgermlines/ et python3Les scripts dans germline/ ne se lancent pas sur une machine récente, sans explicitement rajouter des python2 partout.
Voir aussi #2257.Les scripts dans germline/ ne se lancent pas sur une machine récente, sans explicitement rajouter des python2 partout.
Voir aussi #2257.https://gitlab.inria.fr/vidjil/vidjil/-/issues/4930vidjil.cpp: refactor des appels de création des index2022-01-10T09:12:03+01:00Mathieu Giraudvidjil.cpp: refactor des appels de création des indexDepuis #4845, après !1010:
> Pour une remise à plat du bloc création index (et -2/-4/...) on verra plus tard
Voir le [bilan](https://gitlab.inria.fr/vidjil/vidjil/-/issues/4845#note_568484) fait avant !1010.
Voir aussi (orthogonalement...Depuis #4845, après !1010:
> Pour une remise à plat du bloc création index (et -2/-4/...) on verra plus tard
Voir le [bilan](https://gitlab.inria.fr/vidjil/vidjil/-/issues/4845#note_568484) fait avant !1010.
Voir aussi (orthogonalement ?) #2968 et #1169.https://gitlab.inria.fr/vidjil/vidjil/-/issues/4777Rationaliser les appels à build_from_json2021-04-28T12:10:42+02:00Mathieu GiraudRationaliser les appels à build_from_jsonVu à l'occasion de #4775: il y a deux fois `multigermline->build_from_json()` très semblables (dans les cas standard, le deuxième lance `homo-sapiens/homo-sapiens.g` et ne mène à rien).
Suite de #3293 ?Vu à l'occasion de #4775: il y a deux fois `multigermline->build_from_json()` très semblables (dans les cas standard, le deuxième lance `homo-sapiens/homo-sapiens.g` et ne mène à rien).
Suite de #3293 ?https://gitlab.inria.fr/vidjil/vidjil/-/issues/4659Vérification d'overlap : le faire aussi sur non up/down (bref les V) + refact...2021-01-20T21:09:19+01:00Mathieu GiraudVérification d'overlap : le faire aussi sur non up/down (bref les V) + refactor split-germlinesC'est plus complexe que les choses dans !891 , mais c'est l'occasion de refactorer `split-germlines.py` pour que le même mécanisme sorte les germlines "normales" que les down/up. Sera fait plus tard.C'est plus complexe que les choses dans !891 , mais c'est l'occasion de refactorer `split-germlines.py` pour que le même mécanisme sorte les germlines "normales" que les down/up. Sera fait plus tard.Mathieu GiraudMathieu Giraud