Réécriture de init.sql

init.sql a été réécrit avec ces modifs :

• people a été intégré à kara (c'est une relation 1-n après tout)
• kara.hash a été remplacé par un entier AVEC PRIMARY KEY YESS
• du coup bucket a été supprimé
• changé kara.type et kara.category en kara.categry et kara.lang
• playlist a un INTEGER PRIMARY KEY (de toute façon il était déjà là avec les rowid de sqlite)
• belongs -> kara_playlist avec les ON DELETE CASCADE au lieu des triggers
• history a été remplacé par queue, avec une table queue_state pour sauvegarder l'état de la lecture (c'est plus propre je trouve)
• comme ça recouvre le use case de mpchc, je l'ai supprimée ?

Pour le trigger qui limite la taille de l'historique (de la file du coup), c'est ptet mieux de faire du ratelimit côté applicatif que de s'imposer une limite sur la taille ?

Les triggers sur les playlists protégées servent à rien pck on peut direct SELECT WHERE category = 'bite';

les views. . . rip les views

je ferait une fonction update pour maj la liste des kara

added 1 commit

• f1f95c50 - Update init.sql

Compare with previous version

C'est quoi la diff avec les nouveaux kara ? si c'est juste le chemin vers le kara on peut laisser juste file_path, la fonction de maj de la liste de kara peut s'occuper de voir si un kara est nouveau ou pas.

je viens de voir le commentaire du commit

mentioned in merge request !2 (closed)

en fait ya deux trois trucs à corriger comme le fait que file_path doit etre unique, et ajouter un kara_directory dans misc

et kara.category doit pouvoir etre null pour les kara qui ne sont pas dans une catégorie spécifique ?

Non, un kara a forcément une catégorie, les catégories possibles c'est cdg, vo, va, vf, voca, amv, autres

En gros un kara c'est catégorie/source ou nom de l'anime, jeux, groupe - type, ed, op... - nom de la musique.mkv

Dans le /home/kara qui est la racine de la base, il y a les dossiers de toutes les catégories, et le dossiers des nouveaux karas : /home/kara/nouveau, là par pseudo (Sting et Kubat au hazard) il y a une nouvelle racine de base pour ceux qui ont fait les karas, du coup on a des dossiers du type /home/kara/nouveau/Kubat/{amv,vo,va,cdg} par exemple

J'ai plusieurs questions alors, parce qu'on parle bien de la structure de la db et non de /home/kara ?

Là on essaie de façonner les tables en fonction de la structure des dossiers, alors qu'il serait possible d'enregistrer les catégories/types (j'ai une question sur ça après) directement dans les tags des vidéos.

• TITLE avec un TargetTypeValue de 50 -> le nom de la musique
• TITLE avec un TargetTypeValue de 70 -> le nom de la source
• CONTENT_TYPE (50) -> catégorie (amv,vocaloid,cdg)
• ADDRESS -> la langue (vo, va, vf)
• ARTIST -> l'auteur du kara

Ça aurait comme avantage d'être plus flexible (un kara peut etre va et vocaloid) et de permettre de charger des kara depuis une clef usb/sftp/webdav. ça pourrait complexifier le code d'update de la db mais j'ai pas encore assez réfléchi à ça. (enfin là ça me parrait plus propre que de ranger dans des dossiers, qu'est-ce t'en penses ?)

Oki, je pense que ça peut être bien. Il faut juste trouver un moyen de différencier amv/Toto1 - ED - toto2 et vo/Toto1 - ED - toto2.

Je pense qu'il faut séparer vo/va/vf de la langue, ça peut être un vo et être en anglais, et dans va il y a plein de langues. Du coup plus un truc comme ça :

• TITLE avec un TargetTypeValue de 50 -> le nom de la musique
• TITLE avec un TargetTypeValue de 70 -> le nom de la source
• CONTENT_TYPE (50) -> catégorie (amv,vocaloid,cdg,vo,(va,vf -> à fusionner ?),autres)
• ADDRESS -> la langue (jp, fr, en, ru, sp, it)
• ARTIST -> l'auteur du kara

Après oui, les dossiers c'est bien mais que pour les scripts bash et les recherches vite fais avec le terminal.

Le new c'est juste pratique pour le prez pour voir si un kara est déjà passé ou pas. En soit ça peut ne pas être stocké, il faut juste un moyen de le savoir rapidement.

En soit, ça peut être un champ dans la db, et c'est stocké comme les autres karas, sans dossier bizare.

added 1 commit

• 84af02ff - Ajout de l'empreinte de la base actuelle. Pour avoir les chemin il faut...

Compare with previous version

Ok, cimer pour l'empreinte

je mets filepath en unique et category en not null puis je merge

added 1 commit

• 49e504fb - Juste l'ajout d'un type qui est en gros comme les dossiers actuellements, ça...

Compare with previous version

"Un kara est déjà passé" c'est par rapport à la liste de lecture ? ou "is_new" c'est pour savoir si un kara est dans le dossier nouveau ?

added 1 commit

• 61cf1ed0 - file_path is unique

Compare with previous version

merged

mentioned in commit ffd5b1e2