Piwigo.org

rub · 2005-12-14 00:21:36

Je viens de lire le Wiki Historique des visites et je me poses des petites questions.

Concernant le stockage, je suis d'accord pour les changements apportant des gains de taille de la table.
D'ailleurs, ces modifs permettent de faire suivre les modifications des chemins des images, ... si elles sont été déplacées (sur le serveur + migration des données des tables images).

Bref...

Si un user (ou catégorie, images...) est supprimé, il faut garder l'historique! Ok!

En mode sans suppression, on a accés au nom des éléments (user, catégories, ect...) par jointure sur la bonne table....
Mais quand la donnée a été supprimé que faire? (Afficher un id? Ne pas afficher? ...)
Qu'est ce qui a été prévu?

Moi, je pensais à plusieurs solutions:
Solution 1:
des tables historiques contenant une copie des informations utiles (user, cat, images) avec des id différents que les tables de bases... Pas de soucis pour les users, mais pour les cat et les images ca va faire de beaucoup de données...
Avantages: Plus de soucis aucun sur les noms de users, ect...
Inconvénients: Redondance des données, volume des données

Solution 2:
des tables historiques contenant une copie des informations utiles UNIQUEMENT pour les éléments supprimés. Une table de relation permettra de faire le lien entre les "vrai" tables et les historiques...
Avantages: Pas de pb de volume de données
Inconvénients: Dedondance des données, gestion un peu complexe

Solution 3:
ne pas faire de suppression dans les tables, mais mettre des flags dans chaques tables pour indiquer si la donnée est obsolte ou non...
Avantages: Pas de pb de volume de données, prend tout en compte
Inconvénients: On garde tout, prévoir une purge des données obsolétes (user, images, historique)

Qu'en pensez-vous et qu'est-ce qui est prévu pour le moment?

plg · 2005-12-18 22:10:46

Le bug 164 est vaguement en rapport avec le sujet. J'ai rajouté un lien vers ce topic depuis [wiki] fr:fonctionnalites:historique.

La problématique que tu abordes est importante, surtout que tu nous parles d'un arbre qui cache une forêt. Je m'explique : si le user 1234 est supprimé, l'historique ne pourra plus afficher le nom de l'utilisateur. Ce n'est pas vraiment grave en soit. Par contre, si au moment de sa suppression, le user 1234 est le dernier créé, alors le prochain user prendra l'id... 1234. O rage, o désespoir.

Extrait de include/functions_user.inc.php:register_user

Code:

    // what will be the inserted id ?
    $query = '
SELECT MAX('.$conf['user_fields']['id'].') + 1
  FROM '.USERS_TABLE.'
;';

C'est complètement horrible, je sais. Le principe est d'ailleurs très proche pour les catégories.

Pour en revenir à notre utilisateur 1234, son nom d'utilsateur va simplement "changer".

Traitons ce problème avant le tien ;-)

volcom · 2005-12-19 10:19:43

à mon humble avis, l'espace de stockage ne doit pas être un problème. L'idée des flags me parait pas mal, et si je ne m'abuse c'est la solution choisie la plus souvent... on ne perd pas d'infos, et le problème que tu soulèves z0rglub serait réglé. Par contre, il faudrait modifier pas mal de requêtes de l'application pour ajouter "and ligne.delete != 1" par ex

VDigital · 2005-12-19 14:50:47

Pour moi, le principe de flag évoqué par rub et volcom me semble suffisant.
Il peut même est positionner lors de la migration
Flag des lignes de l'historique si la catégorie est plus récente que l'enregistrement de histo, et/ou le user est plus récent que la ligne de l'histo (faut-il encore avoir la date du user, et ça je n'ai pas contrôlé).

nicolas · 2005-12-19 23:22:31

z0rglub a écrit:
Extrait de include/functions_user.inc.php:register_user
Code:
    // what will be the inserted id ?
    $query = '
SELECT MAX('.$conf['user_fields']['id'].') + 1
  FROM '.USERS_TABLE.'
;';
C'est complètement horrible, je sais. Le principe est d'ailleurs très proche pour les catégories.

C'est vraiment horrible! :-) Tu seras fouetté avec le grand fouet de Rasmus sur la place publique!

Pourquoi se préoccuper de l'id que tu insères ? Lorsque j'insère un nouvel enregistrement dans une table avec une clé primaire auto-incrémentée je fais une requête de ce genre sur ma table (id, nom, prenom, age):
insert into ma_table (nom,prenom,age) values('Nicolas','Cémoi',10);
L'id de cet utilisateur au prénom magnifique sera le plus grand. mysql ne bouche pas les trous et on s'en moque.

p.s: désolé pour le hors sujet.

rub · 2005-12-19 23:39:29

z0rglub a écrit:
Code:
    // what will be the inserted id ?
    $query = '
SELECT MAX('.$conf['user_fields']['id'].') + 1
  FROM '.USERS_TABLE.'
;';
C'est complètement horrible, je sais. Le principe est d'ailleurs très proche pour les catégories.
[...]
Traitons ce problème avant le tien ;-)

Les propositions pour résoudre ce pb?
Moi, j'aime les séquences, mais apparement, en MySql, c'est pas connu... (C'est sur?)
il y a aussi les colonnes auto-incrémentées (mais pas encore testée).

Sinon, si pas de séquence , on peut passer par une table de "séquence" (champs type/table, current number id) pour séquencer les différents id des tables (voir un id unique quelque soit la donnée).

C'est vrai que le max c'est simple à faire mais un jour ou l'autre, on a des petits soucis (pas bien grave la plupart du temps)

volcom a écrit:
à mon humble avis, l'espace de stockage ne doit pas être un problème.

C'est vrai.

volcom a écrit:
L'idée des flags me parait pas mal, et si je ne m'abuse c'est la solution choisie la plus souvent... on ne perd pas d'infos, et le problème que tu soulèves z0rglub serait réglé. Par contre, il faudrait modifier pas mal de requêtes de l'application pour ajouter "and ligne.delete != 1" par ex

On peut aussi passer par des vues ( a voir si performant pour les requêtes en mysql?) ca evite de modifier les sql et ca fait des requetes plus lisibles.
On renomme les tables en mytable_full (par exemple) , on crée un vue mytable (avec where sur flag)... il suffit de changer les sql de mise à jour (sauf si les views peuvent être en écriture en mysql, à voir?)

VDigital a écrit:
Pour moi, le principe de flag évoqué par rub et volcom me semble suffisant.

Je pense que les 2 sont ncéssaire par contre.
Les flags sont bien pour résoudre le pb des historiques, etc.
Mais même si l'on veut garder toutes les données, il y a toujours un moment, où il sera nécessaire de faire des deletes (soit pas script ou à la main) (pour un migration, une purge, et j'en passe)
Et la, le pb du max ne doit plus en être un...

VDigital a écrit:
Il peut même est positionner lors de la migration

Je pense même qu'il faudrait absolument positionner ces flags lors de migration.

De plus, ces flags ne doivent pas être boolean mais plus une ensemble de status (valid, invalid, supprimer, processing, migrated, etc...)
ca pourrait être utile pour des prochaines évolutions.
Et les status pourrait être même cumulatitfs (par système de and binaire). Par exemple, invalid et migrated.
Pour notre cas, on aura simplement besoins des status (valided, deleted voir migrated)...

PS: Sur mes propositions de séquences, view, je me base sur mes expérience en oracle mais je ne sais pas si c'est possible ou performant en MySql...

rub · 2005-12-19 23:48:27

nicolas a écrit:
Pourquoi se préoccuper de l'id que tu insères ? Lorsque j'insère un nouvel enregistrement dans une table avec une clé primaire auto-incrémentée je fais une requête de ce genre sur ma table (id, nom, prenom, age):
insert into ma_table (nom,prenom,age) values('Nicolas','Cémoi',10);

Par contre, quels sont les inconvenients de l'auto-incrémentée pour des traitements de migrations, ou il est necessaire de réinserer des engegistrements ou pour une reprise d'historique. Il va peut-être falloir faire un alter sur la table pour ne plus auto-incrémenter, ect...
Il faut aussi avec quelle version de mysql, c'est compatible et ca convient avec les versions compatibles de PWG...

Après insertion, est_il de récuperer les id?
L'auto-incrémenté me semble pratique et mais avec qques inconvénient...

Et on est justement la pour discuter des solutions possibles et faire le récap des point - et des points +...

nicolas a écrit:
L'id de cet utilisateur au prénom magnifique sera le plus grand. mysql ne bouche pas les trous et on s'en moque.

C'est vrai...

volcom · 2005-12-20 10:01:36

rub : http://mysql.developpez.com/faq/?page=C … ILITE_vues

Visiblement MySQL supporte les vues mais dans une version très récente. La plupart des installations de MySQL sont en 3.x voir 4.x (Free)... il va être difficile d'utiliser les vues.

rub · 2005-12-20 12:18:35

volcom a écrit:
Visiblement MySQL supporte les vues mais dans une version très récente.
[...]il va être difficile d'utiliser les vues.

Ca me rend triste ca!
Il faudrait donc essayer de passer par un variable globale contenant les clauses where à inclure dans chaque requete? Pour éviter de tous modifier à chaque fois...

Et pourquoi pas (mais bof), prévoir dans le code de passer un jour au vues quand ca sera bien déployé, utilisé... (en utilisant des variables différentes pour les noms de tables suivant full ou restreint)...

volcom · 2006-04-10 16:00:38

je remonte le sujet car je m'attaque à la structure de la table de l'évolution historique.

Comment procède t-on pour les éléments supprimés dont on a plus que l'id (user, image, categorie ?) ?

Est on d'accord sur la structure de la base évoquée dans les spec du Wiki ?

Je ne me suis pas encore plongé dans les changements de la 1.6, quid des catégories ?

volcom, (un peu largué...)

VDigital · 2006-04-21 17:42:32

Je rrrreeemonte le sujet.

Il y a quelques jours Mareva78 avait un problème d'accent et à cette occasion, j'ai redécouvert un projet GPL qui s'appelle phpMyVisites.

Je l'avais testé en 1.5, je n'en voyais pas l'intérêt.
Sauf que je ne me bloque pas sur ma première idée et que j'ai décidé de ré-examiner la question.

Pourquoi?

Un projet qui gère des Stats les gèrera mieux que nous.
Un projet qui évolue ( phpMyVisites 2.1 ) nous permet de consacrer nos efforts sur ce que nous savons faire et devons faire "Présenter des images".

Alors premières conclusions:
- Il compresse ses stats...
- Il permet de "stater" certaines pages ou toutes, des users et pas d'autres...
- Tout plein de bonnes idées ( à ne pas reprendre forcément dans notre PWG )
- Il permet de "stater" sur un site ses autres sites (donc aurevoir les problèmes d'espace)
- Il fait du RSS

Est-il adaptable à PWG:
Stats sur ID &| nom de la catégorie, je suis certain que oui.
Stats sur ID &| nom de l'image, bien entendu.
Stats avec le lien vers la miniature, j'en suis presque convaincu...
mais des tests restent à faire.
Peut-on exclure l'admin PWG? Oui dans une grande majorité des cas (voire même à 100%)...

Inconvénient: Javascript actif pour être inclus dans les stats d'où l'historique conservé en PWG.
Mais on a de bonnes stats (ce sont des stats).

Faut-il supprimer l'historique de PWG pour autant?
Non... Probablement pas (Je n'ai pas vu l'option voir l'historique détaillé).
Pour ceux qui ne conservent pas déjà le moindre historique, c'est sans problème.
Mais on peut réduire le nôtre... Catégorie inutile, par exemple.
Profondeur, c'est certain.
Historique dans PWG si Javascript inactif, why not?
Pas d'historique dans PWG si Javascript actif, ben voyons...
(A voir le contenu de ses tables pour savoir si le détail est reconstituable).

Un lien optionnel vers le site phpMyVisites qui stats la galerie... Why not a MOD?
Lien en Admin bien entendu.

Faire un MOD qui affiche dans PWG le détail de l'historique de la galerie contenu dans le site de phpMyVisites.
Pas totalement absurde...

Je pousse plus loin mes tests et j'explique comment ça peut très très très très très très très très très très bien marcher.

C'est une petite idée comme ça. (Merci Mareva78).

8-)

plg · 2006-04-21 18:20:12

VDigital, il est impossible qu'un produit générique puisse faire ce que la refonte de l'historique propose, impossible. Il pourra faire mieux qu'actuellement en 1.6, mais pas mieux que la future refonte (si elle a lieu, clin d'oeil à volcom).

VDigital · 2006-04-21 18:41:52

Je n'en dit pas plus et je donnerai des exemples.
Je suis d'accord qu'on peut toujours faire mieux et le survol affichant la miniature sur l'historique détaillé restera un must.

rub · 2006-04-21 23:27:06

Mais que veut-on pour PWG? Un historique ou des stats? Même si elles sont liées ces notions sont différentes...

nicolas · 2006-04-21 23:28:37

rub a écrit:
Mais que veut-on pour PWG? Un historique ou des stats? Même si elles sont liées ces notions sont différentes...

c'est clair et personnellement je n'aime pas les scripts dans le genre de phpmyvisites

Piwigo.org

Annonce

#1 2005-12-14 00:21:36

[Evolution Prévue dans v1.6.0] Refonte des historiques...

#2 2005-12-18 22:10:46

Re: [Evolution Prévue dans v1.6.0] Refonte des historiques...

Code:

#3 2005-12-19 10:19:43

Re: [Evolution Prévue dans v1.6.0] Refonte des historiques...

#4 2005-12-19 14:50:47

Re: [Evolution Prévue dans v1.6.0] Refonte des historiques...

#5 2005-12-19 23:22:31

Re: [Evolution Prévue dans v1.6.0] Refonte des historiques...

z0rglub a écrit:

Code:

#6 2005-12-19 23:39:29

Re: [Evolution Prévue dans v1.6.0] Refonte des historiques...

z0rglub a écrit:

Code:

volcom a écrit:

volcom a écrit:

VDigital a écrit:

VDigital a écrit:

#7 2005-12-19 23:48:27

Re: [Evolution Prévue dans v1.6.0] Refonte des historiques...

nicolas a écrit:

nicolas a écrit:

#8 2005-12-20 10:01:36

Re: [Evolution Prévue dans v1.6.0] Refonte des historiques...

#9 2005-12-20 12:18:35

Re: [Evolution Prévue dans v1.6.0] Refonte des historiques...

volcom a écrit:

#10 2006-04-10 16:00:38

Re: [Evolution Prévue dans v1.6.0] Refonte des historiques...

#11 2006-04-21 17:42:32

Re: [Evolution Prévue dans v1.6.0] Refonte des historiques...

#12 2006-04-21 18:20:12

Re: [Evolution Prévue dans v1.6.0] Refonte des historiques...

#13 2006-04-21 18:41:52

Re: [Evolution Prévue dans v1.6.0] Refonte des historiques...

#14 2006-04-21 23:27:06

Re: [Evolution Prévue dans v1.6.0] Refonte des historiques...

#15 2006-04-21 23:28:37

Re: [Evolution Prévue dans v1.6.0] Refonte des historiques...

rub a écrit:

Pied de page des forums