ahhhhhhhhhhhhhhhh j'ai failli despérer que quelqu'un me réponde :)

comme z0rglub il me semble que la refonte de l'historique a des interêts différents... Les besoins particuliers de statistiques sur les images, les utilisateurs me semblent difficilement réalisables par PMV (même s'il y a quelques temps que je n'ai pas vu le "produit")

Pour le clin d'oeil, je voudrais bien qu'on s'entende sur certains points, notamment les problèmes de pérennité des données de l'historique, ça remet en cause beaucoup de choses, notamment dans la table des images. Je ne sais pas trop par ou commencer ( et je vais bien devoir puisque j'ai quand même un projet à rendre très bientot )

Je pense commencer une sorte de maquette pour le coté scolaire "de mon coté" et ce sera une bonne base pour nos réflexions à venir.

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

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).

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é...)

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.

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...

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é).

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

    // 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 ;-)