Behavior in case of deletion

[oliverpool]

Histoire de faire un truc clair (et si possible avoir une conclusion définitive).

Comment veut-on gérer les suppressions des éléments suivants (et dans quels cas une telle suppression à lieu):

• utilisateur
• chant
• artiste
• carnet
• repository

[oliverpool]

Je propose:

utilisateur

Ses carnets sont supprimés ("désinscription")

carnet

Suppression des éléments relatifs au carnet (seulement des liaisons)

artiste
chant

Suppression des chants et de l'artiste correspondant, aucune compilation possible à l'avenir (la suppression est demandée par les ayants droits)

repository

Suppression des chants concernés, et des artistes si ils n'ont plus de chant

Ma proposition est assez extrême : si des éléments ont été supprimés, ils ne sont pas récupérables et ne seront pas compilés

[Luthaf]

utilisateur

La politique "traditionnelle" de Django dans ce cas est d'utiliser le champ is_active en le mettant à False. L'utilisateur ne peut plus se connecter, mais on garde les données (je crois que l'on est obligé de toute façon).

Pour le reste, je suis d'accord avec toi. Il reste quand même le cas d'une suppression pour cause de duplication. On peut ajouter quelques méthodes pour gérer ça.

[oliverpool]

utilisateur

ok pour le désactiver, mais est-ce qu'on garde ses carnets de chants ? (publics / privés)

[Luthaf]

Les publics oui, et les privés, ça ne coute pas grand chose en fait.

[oliverpool]

Ben, ca dépend de la forme de stockage des carnets de chants (à l'heure actuelle c'est quand même pas mal de lignes dans pas mal de tables différentes)

[Luthaf]

Pour les carnets, on est pas obligé de les supprimer (il n'y a pas de problème légal je pense), et même si on a 2000 utilisateurs, avec 4 carnets chacun, ça fait quelque chose comme 20 000 entrée dans la base. Ce n'est pas forcément très grave.

Mais oui, on peut aussi supprimer les entrées correspondants aux carnets privés dans le cas d'une demande de suppression de compte par l'utilisateur.

[oliverpool]

Un carnet c'est une entrée dans la table "Songbook" et une centaine dans la table "ItemsInSongbook" (+ SongInSongbook, ArtisitInSongbook)... ca fait un peu plus que 20 000!

Mais oui, on peut aussi supprimer les entrées correspondants aux carnets privés dans le cas d'une demande de suppression de compte par l'utilisateur.

Dans ce cas, il peut les supprimer lui-même avant de demander la suppression

[Luthaf]

Pas faux =)

Je vais regarder s'il y a un signal Django de désactivation d'un utilisateur. Il pourrait servir à supprimer ses carnets lors de la désactivation, en filtrant les carnets privé/publics.

[jmclem]

@oliverpool : je te sens très crispé à l'égard de ce que j'ai codé; c'est pas la peine :) : comme je l'ai déjà dit, si ce n'est pas la bonne solution, je n'ai aucun problème à le modifier.

Revenons à la discussion.

Est-ce-que je me trompe, où on se retrouve peu à peu dans le cas proposé il y a une semaine :

• on balance la gestion de version par dessus bord et on ne travaille qu'avec la dernière version d'un chant. Si le chant n'existe plus, il disparaît du carnet. Si quelqu'un a renommé/déplacé un fichier, il disparaît, à l'utilisateur de retourner inclure à nouveau le chant.

?

Parce que, pour la cohérence, je ne vois pas pourquoi s'embêter à gérer d'anciennes versions de chants pour des carnets existants alors qu'on supprime des carnets les chants qui disparaissent de la repo.

Je penche de plus en plus pour cette solution. On oublie les différentes versions de chants pour les différents carnets; il y a une version : celle du head, point barre. Au moins dans un premier temps. Je pense qu'il sera possible de revenir dessus si un fort souhait s'exprimait.

Pour l'archivage, on explique aux utilisateurs qu'ils sont responsables de la conservation de leur PDF, et que rien ne garantit qu'ils pourront le regénérer tel quel.

[Luthaf]

Parce que, pour la cohérence, je ne vois pas pourquoi s'embêter à gérer d'anciennes versions de chants pour des carnets existants alors qu'on supprime des carnets les chants qui disparaissent de la repo.

Pour moi ce n'est pas la même chose : on supprime les carnets en même temps que les utilisateurs, et les chants si on a la demande des ayant-droits, mais on garde la possibilité qu'il existe plusieurs versions, et on laisse aux utilisateur le choix de la leur.

Au moins dans un premier temps. Je pense qu'il sera possible de revenir dessus si un fort souhait s'exprimait.

Ça peut en effet être une solution : on lance le truc, puis on demande s'il y a des intéressés =)

[oliverpool]

Au moins dans un premier temps. Je pense qu'il sera possible de revenir dessus si un fort souhait s'exprimait.

Ça peut en effet être une solution : on lance le truc, puis on demande s'il y a des intéressés =)

Effectivement c'est une bonne idée. En plus, une fois le site lancé, les utilisateurs auront peut-être des besoins et des idées différentes !

---

@oliverpool : je te sens très crispé à l'égard de ce que j'ai codé; c'est pas la peine :) : comme je l'ai déjà dit, si ce n'est pas la bonne solution, je n'ai aucun problème à le modifier.

"Crispé" est peut-être un peu fort (et de toute les manières, je continuerai de contribuer au design, quelque soit le back-end ;-)

---

Donc du coup on on dit que dans un premier temps on supporte une seule version (l'actuelle) ?
Ça simplifie la BDD et la génération du pdf (on peut utiliser les mêmes fichiers). Et pour la suite, on verra en fonction des souhaits/avis utilisateurs ?
[et puis du coup on se rapproche de notre ligne de conduite initiale : avoir quelque chose de simple, mais fonctionnel]

[Luthaf]

Allons-y !

Je propose aussi une remise à plat des migrations south au passage, j'ai eu quelques difficultés pour passer à la dernière version =)

[jmclem]

Ok !

Quelques aspects qui en découlent :

• on garde l'object hash, le commit hash n'est plus nécessaire. A-t-on besoin d'une table GitFile ? On pourrait mettre l'object hash et le chemin dans Song à mon avis.
• Quand un chant est supprimé : on pourrait garder le Song et mettre le chemin à NULL. Ainsi, il est possible de faire savoir à l'utilisateur que le chant "Tralala" a été supprimé et ne peut plus être utilisé pour générer un carnet
• ceci est valable quelque soit la source de suppression : via l'application par un admin ou via un pull sur la repo
• On peut aujourd'hui importer (importsongs), il va falloir une fonction de mise à jour (même script avec des paramètres ou second script). En comparant les object hashes, il sera possible de savoir qu'une mise à jour d'un chant est nécessaire et de la faire. Il faudra aussi vérifier quels chants en db n'ont plus de fichier correspondant (en essayant de détecter les déplacements / renommages)
• Tous les *InSongbook peuvent disparaître

[oliverpool]

• Quand un chant est supprimé : on pourrait garder le Song et mettre le chemin à NULL. Ainsi, il est possible de faire savoir à l'utilisateur que le chant "Tralala" a été supprimé et ne peut plus être utilisé pour générer un carnet

Excellente idée !

• On peut aujourd'hui importer (importsongs), il va falloir une fonction de mise à jour (même script avec des paramètres ou second script). En comparant les object hashes, il sera possible de savoir qu'une mise à jour d'un chant est nécessaire et de la faire. Il faudra aussi vérifier quels chants en db n'ont plus de fichier correspondant (en essayant de détecter les déplacements / renommages)

Bonne idée aussi (mais qui va pas être évidente à coder).
Ça pose aussi la question de gérer plusieurs repo (dans un premier temps, on peut dire que non...)

[jmclem]

Ça pose aussi la question de gérer plusieurs repo

et de différents types : fs simple, vcs, db, web api, ... rhôôoô, c'est bô...

dans un premier temps, on peut dire que non...

oui, heu... non... enfin, on est raisonnable et on attend, quoi ;)

[Luthaf]

A-t-on besoin d'une table GitFile ? On pourrait mettre l'object hash et le chemin dans Song à mon avis.

Et pourquoi pas dans une classe abstraite dont hériterai Song ? Ce n'est pas beaucoup plus compliqué, et on peut aussi s'en servir pour d'autres types de fichiers : illustrations d'albums, intersongs, chants persos, ...

[jmclem]

Et pourquoi pas dans une classe abstraite dont hériterai Song ?

parce qu'un fichier n'est pas une généralisation d'un chant pour notre application, ça irait donc contre un des principes de l'OOP. À juste titre : je peux envisager d'avoir des chants qui n'ont qu'une représentation en BDD, ou que je récupère via une API Web, auquel cas l'abstraction imposée 'GitFile' me gènerait.

on peut aussi s'en servir pour d'autres types de fichiers : illustrations d'albums, intersongs, chants persos, ...

... qui peuvent aussi avoir d'autres formes de stockage qu'un fichier GIT (URL, ...).

Ce qui serait (enfin, sera un jour peut-être ;) ) envisageable, c'est de faire une abstraction "stockage" qui se spécialise en "gitfile", "db", "webapi", "url", "file", ... pour couvrir différents modes de stockage des éléments. Toutefois, pour l'instant, je suis de l'avis que :

enfin, on est raisonnable et on attend, quoi ;)

[Luthaf]

Ça me va =)

[Luthaf]

Alors je reviens sur cette issue avec l'état actuel du projet

Quand un chant est supprimé : on pourrait garder le Song et mettre le chemin à NULL. Ainsi, il est possible de faire savoir à l'utilisateur que le chant "Tralala" a été supprimé et ne peut plus être utilisé pour générer un carnet

Plutôt que de mettre le chemin à NULL, je propose de mettre le hash à NULL. Comme ça la même fonction de comparaison que pour les mises à jour peut être utilisée pour les suppressions.

On peut aujourd'hui importer (importsongs), il va falloir une fonction de mise à jour (même script avec des paramètres ou second script). En comparant les object hashes, il sera possible de savoir qu'une mise à jour d'un chant est nécessaire et de la faire. Il faudra aussi vérifier quels chants en db n'ont plus de fichier correspondant (en essayant de détecter les déplacements / renommages)

Le même script doit pouvoir servir directement : on effectue l'import des nouveaux chants, la mise à jour des chants existants (mise à jour du hash). Là ou je bloque par contre est sur les renommages/suppression et comment faire la différence entre ces deux.

On peut essayer de regarder l’historique des fichiers et détecter si il y a une différence ? Cela semnle possible à coups de GitPython (http://pythonhosted.org/GitPython/0.3.1/reference.html#git.diff.Diff), mais pas évident si le diff contient beaucoup de fichiers.