Piwigo.org

VDigital · 2006-11-15 15:14:35

Pourquoi ne pas gérer une last date au niveau des catégories...?

Maintenance: mise à jour des catégories à recommander suite à une synchro (cas des suppressions).

Processus d'association des images à une catégorie: si plus récente => maj de la last date.
Processus de dissociation: si date égale => en fin de dissociation multiple, recalcul de la last date de la catégorie.

Processus de synchro des métadonnées (voire même de synchro pure et dure, si on pense que la technique de Laurent le supportera) mais uniquement sur les ajouts.

Dirais-je une petite sornette?

8-)

plg · 2006-11-15 15:50:58

rub a écrit:
z0rglub a écrit:
Rub, quelle est ta stratégie pour ce dev ? Je peux t'en proposer une si tu veux.
[...]
z0rglub, quelle était la tienne?

Si on prend en compte les sous-catégories, le date_last d'une catégorie dépend des date_lasts des sous-catégories. Or, la liste des sous-catégories d'une catégorie est liée aux permissions de l'utilisateur. Donc en théorie, chaque utilisateur a une date_last différente pour chaque catégorie. Cette valeur n'est susceptible de changer qu'à chaque changement de permissions.

Pour moi, on est en présence évidente d'un candidat pour une nouvelle colonne #user_cache.categories_date_last qui contiendrait une sérialisation d'un tableau associatif qui à chaque identifiant de catégorie associerait une date_last. L'utilisation de #user_cache permet de ne générer le cache que très rarement pour une utilisation très fréquente (chaque rafraichissment de page).

Si on n'utilise pas #user_cache, on va faire fréquemment le même calcul et cela n'aura pas le moindre intérêt.

rub · 2006-11-15 16:32:55

VDigital a écrit:
Dirais-je une petite sornette?

Cf ce que dit z0rglub, c'est parce que c'est différent pour chaque.

z0rglub a écrit:
Pour moi, on est en présence évidente d'un candidat pour une nouvelle colonne #user_cache.categories_date_last qui contiendrait une sérialisation d'un tableau associatif qui à chaque identifiant de catégorie associerait une date_last. L'utilisation de #user_cache permet de ne générer le cache que très rarement pour une utilisation très fréquente (chaque rafraichissment de page).
Si on n'utilise pas #user_cache, on va faire fréquemment le même calcul et cela n'aura pas le moindre intérêt.

Bonne idée, ce nouveau champ dans #user_cache.
Même si le calcul semble rapide.
On peut aussi faire une nouvelle table, si #user_cache.need_update, on remet à jour la table pour le user. L'avantage, c'est l'exploitation directement dans les requêtes par jointure.

Tu veux ça dans Alligator? Tu veux garder l'ancien mode de fonctionnement aussi? (perso, je ne suis pas pour).

plg · 2006-11-15 16:51:07

rub a écrit:
Même si le calcul semble rapide.

Le calcul n'est pas si rapide que ça non. On a du récursif quand même ! Et puis c'est surtout la répétition d'un calcul donnant toujours le même résultat qui me gêne.

rub a écrit:
On peut aussi faire une nouvelle table, si #user_cache.need_update, on remet à jour la table pour le user. L'avantage, c'est l'exploitation directement dans les requêtes par jointure.

C'est exactement ce que j'avais en 1.3.1... et abandonné en 1.4, tu peux chercher la table #user_category en 1.3.4 pour te faire une idée. Franchement, cela sera plus simple et rapide d'avoir un tableau sérialisé dans #user_cache, c'est moins intrusif dans le code actuel je pense. A toi de décider quand même, faut que tu te fasses plaisir :-). L'important c'est de mettre en évidence le caractère "cache" de ces informations.

La bonne question à se poser, c'est "pourquoi la méthode introduite en 1.3.1 a été abandonnée en 1.4 ?". Parce que le rafraichissement de ces informations n'était pas fait utilisateur par utilisateur lorsqu'il se connecte sur la partie publique mais pour tous les utilisateurs quand l'admin changeait les permissions. Du coup une galerie avec 1000 utilisateurs et 500 catégories devait calculer et insérer 500,000 lignes dans la table, en une seule opération : désastreux. Avec la méthode que je propose, cela devient 500 lignes à calculer et insérer à la fois, au fur et à mesure des connexions utilisateurs après modif des permissions par l'admin. Cela devient presque transparent en terme de perf et indépendant du nombre d'utilisateurs.

Tu veux ça dans Alligator? Tu veux garder l'ancien mode de fonctionnement aussi? (perso, je ne suis pas pour).

Va pour Alligator, pas d'intérêt de garder l'ancien mode de fonctionnement.

rub · 2006-11-15 17:43:45

z0rglub a écrit:
rub a écrit:
Même si le calcul semble rapide.
Le calcul n'est pas si rapide que ça non. On a du récursif quand même ! Et puis c'est surtout la répétition d'un calcul donnant toujours le même résultat qui me gêne.

Oui, oui, je suis d'accord avec toi.
Dans un premier temps, je me suis amusé à faire l'algo de mise à jour des last_date.

z0rglub a écrit:
rub a écrit:
On peut aussi faire une nouvelle table, si #user_cache.need_update, on remet à jour la table pour le user. L'avantage, c'est l'exploitation directement dans les requêtes par jointure.
C'est exactement ce que j'avais en 1.3.1... et abandonné en 1.4, tu peux chercher la table #user_category en 1.3.4 pour te faire une idée. Franchement, cela sera plus simple et rapide d'avoir un tableau sérialisé dans #user_cache, c'est moins intrusif dans le code actuel je pense. A toi de décider quand même, faut que tu te fasses plaisir :-). L'important c'est de mettre en évidence le caractère "cache" de ces informations.

La bonne question à se poser, c'est "pourquoi la méthode introduite en 1.3.1 a été abandonnée en 1.4 ?". Parce que le rafraichissement de ces informations n'était pas fait utilisateur par utilisateur lorsqu'il se connecte sur la partie publique mais pour tous les utilisateurs quand l'admin changeait les permissions. Du coup une galerie avec 1000 utilisateurs et 500 catégories devait calculer et insérer 500,000 lignes dans la table, en une seule opération : désastreux. Avec la méthode que je propose, cela devient 500 lignes à calculer et insérer à la fois, au fur et à mesure des connexions utilisateurs après modif des permissions par l'admin. Cela devient presque transparent en terme de perf et indépendant du nombre d'utilisateurs.

Sur, que c'est le cache qui compte.
De tout façon, que ca soit une nouvelle table ou un nouveau champ, le calcul ne fait que user par user.

Les avantages de l'ajout d'un nouveau champ:
o simplicité pour stocker
o facile à utiliser
Les inconvénients:
o non utilisables dans une requête
o tableau à changer en mémoire (liste de id et de date)
o tableau à parcourir pour chaque catégories

Les avantages de l'ajout d'une nouvelle table:
o simplicité pour stocker
o utilisation directes dans les requêtes
o rien à stocker en php
o ni traitement en php
Les inconvénients:
o plus lourd à mettre en place

Franchement, je ne sais pas encore ce que je vais faire.

Nicco · 2006-11-15 18:33:16

Salut salut,

comme d hab je lis un peu tout les sujet !!! et je trouve ca cool car je comprend et j apprend de nouveaux trucs ...

du coup l explication sur le recurssif et la table cache c est interressant et ca serai bien de l expliquer dans le poste sur gmap non ?

car a l epoque quand on en a parlé je crois que hugo est parti sur une idee similaire a ce que z0rglub a expliqué sur la version 1.3.4

je ne vous derange pas plus longtemps a+

plg · 2006-11-15 18:42:07

rub a écrit:
[...] nouveau champ [...] inconvénients:
[...]
o tableau à parcourir pour chaque catégories

"parcourir" ???, moi je fais juste

Code:

$date_last = $user_date_last[$category_id];

C'est un tableau associatif, pas un tableau simple.

rub · 2006-11-15 18:52:52

z0rglub a écrit:
rub a écrit:
[...] nouveau champ [...] inconvénients:
[...]
o tableau à parcourir pour chaque catégories
"parcourir" ???, moi je fais juste
Code:
$date_last = $user_date_last[$category_id];
C'est un tableau associatif, pas un tableau simple.

C'est pour créer le tableau $user_date_last que je parlais de parcourir, je n'ai pas été assez précis.
Car que va-t-on avoir dans #user_cache.cat_date_last?
Un truc comme ca "cat_id1,date1 | cat_id2,date2 | ... | cat_id3,date3"?
Donc, il faut faire une explode "|" de cette chaine texte puis pour chaque élement (c'est ici qu'on parcoure ;-)) un explode ","?
Si il y a plus simple, je suis preneur. (Je n'ai pas trop pratiqué des preg_*, etc.)

VDigital · 2006-11-15 18:55:38

Je me suis probablement mal exprimé...

La plus récente d'une catégorie est unique.
Elle ne change pas en fonction des droits.

J'explique, même si c'est un peu en vrac, je l'admets.

Si je gère last_date au niveau des catégories...
Je ne gère cette last_date que pour les images de cette catégorie.
Si cette catégorie ne contient pas d'image (cas des catégories parentes), la last_date sera Null.

Solutions:
1 - La date dans le cache si elle vient des images, à chaque fois qu'on invalide un droit on invalide le cache et on re-scanne toutes les images de la catégorie pour alimenter correctement le cache.
2 - La date dans le cache si elle vient des catégories, j'ai un accès à la catégorie.

Dans tous les cas, les last_date des catégories filles/parentes sont à considérer au moment du rechargement du cache.

Moins de requêtes si on se base sur les last_date de chaque catégorie.
Dans la solution 2, la last_date remontée est bien fonction des autorisations liées au visiteur.
On élimine un certain nombre de scan de la table images (c'est bien l'une des tables les plus sollicités même si ce n'est pas la première).

Si tu ne cherches les last_date que dans les catégories, ton algo devrait en être allégé.

Les last_dates sont toujours mises à jour par l'ajout mais pas systématiquement (beaucoup de dates sont identiques lors d'un ajout d'images).

A priori elles ne le sont pas par le retrait, simplement parce que la tendance est:
- Soit j'enlève la toute dernière mais pour la remettre sous un autre nom (la date ne change pas ou elle se rafraîchie encore).
- Soit j'enlève des images mais se sont des anciennes et la date ne change pas.

Au final, AMHA ton algo n'en serait que plus simple.
Si ce n'est pas clair, je suis prêt à détailler.

8-)

rub · 2006-11-15 19:06:21

VDigital a écrit:
...
2 - La date dans le cache si elle vient des catégories, j'ai un accès à la catégorie.
...

On est OK.
Je suis parti sur les infos date_last des catégories (elle-même venant des images), le cache doit être mise à jour si une date_last d'une catégorie change.

On est bien sur la même longeur d'onde? ;-)

De toute façon, ce soir ou demain, je vous -//:---\spam un petit exemple de l'algo applicable pour les menus.

coolsocks · 2006-11-15 19:39:53

Je prnds le post en ratard mais c'set cool, merci à tous ...

rub · 2006-11-16 00:10:24

Pour avoir la petite icône de notification sur les catégories parentes (fonctionne uniquement sur les menus).

Dans le fichier functions_html.inc.php:
Chercher la fonction get_html_menu_category

Code:

    if ($category['nb_images'] > 0)
    {
      $menu.= "\n".'<span class="menuInfoCat"';
      $menu.= ' title="'.$category['nb_images'];
      $menu.= ' '.$lang['images_available'].'">';
      $menu.= '['.$category['nb_images'].']';
      $menu.= '</span>';
      $menu.= get_icon($category['date_last']);
    }

à remplacer par

Code:

    if ($category['nb_images'] > 0)
    {
      $menu.= "\n".'<span class="menuInfoCat"';
      $menu.= ' title="'.$category['nb_images'];
      $menu.= ' '.$lang['images_available'].'">';
      $menu.= '['.$category['nb_images'].']';
      $menu.= '</span>';
    }
    $menu.= get_icon($category['date_last']);

Dans le fichier functions_category.inc.php:
Chercher la fonction get_categories_menu

Code:

function get_categories_menu()
{
  global $page,$user;
...
}

à remplacer par ces 2 fonctions

Code:

function compute_branch_cat_date_last(&$cats, &$list_cat_id, &$level, &$ref_level)
{
  $date = '';
  do
  {
    $cat_id = array_pop($list_cat_id);
    if (!is_null($cat_id))
    {
      if ((empty($cats[$cat_id]['date_last'])) or ($cats[$cat_id]['date_last'] < $date))
      {
        $cats[$cat_id]['date_last'] = $date;
      }
      else
      {
        $date = $cats[$cat_id]['date_last'];
      }
      $ref_level = substr_count($cats[$cat_id]['global_rank'], '.') + 1;
    }
    else
    {
      $ref_level = 0;
    }
  } while ($level <= $ref_level);

  // Last cat updating must be added to list for next branch
  if ($ref_level <> 0)
  {
    array_push($list_cat_id, $cat_id);
  }
}

function get_categories_menu()
{
  global $page,$user;

  $infos = array('');

  $query = '
SELECT name,id,date_last,nb_images,global_rank,id_uppercat
  FROM '.CATEGORIES_TABLE.'
  WHERE 1 = 1'; // stupid but permit using AND after it !
  /*if (!$user['expand'])
  {
    $query.= '
    AND (id_uppercat is NULL';
    if (isset($page['category']))
    {
      $query.= ' OR id_uppercat IN ('.$page['uppercats'].')';
    }
    $query.= ')';
  }*/
  if ($user['forbidden_categories'] != '')
  {
    $query.= '
    AND id NOT IN ('.$user['forbidden_categories'].')';
  }
  $query.= '
;';

  $result = pwg_query($query);
  $cats = array();
  while ($row = mysql_fetch_array($result))
  {
    $cats += array($row['id'] => $row);
  }
  usort($cats, 'global_rank_compare');

  $ref_level = 0;
  $level = 0;
  $list_cat_id = array();

  foreach ($cats as $id => $category)
  {
    $level = substr_count($category['global_rank'], '.') + 1;
    if ($level > $ref_level)
    {
      array_push($list_cat_id, $id);
    }
    else
    {
      compute_branch_cat_date_last($cats, $list_cat_id, $level, $ref_level);
      array_push($list_cat_id, $id);
    }
    $ref_level = $level;
  }

  $level = 1;
  compute_branch_cat_date_last($cats, $list_cat_id, $level, $ref_level);

  if (!$user['expand'])
  {
    $no_expand_cats = array();
    $list_id_uppercat = array();
    if (isset($page['category']))
    {
      $list_id_uppercat = explode(',', $page['uppercats']);
    }
    foreach ($cats as $id => $category)
    {
      if (empty($category['id_uppercat']) or in_array($category['id_uppercat'], $list_id_uppercat))
      {
        $no_expand_cats += array($category['id'] => $category);
      }
    }
    $cats = $no_expand_cats;
  }

  return get_html_menu_category($cats);
}

rub · 2006-11-16 00:15:51

z0rglub a écrit:
...A toi de décider quand même, faut que tu te fasses plaisir :-)...

Je penses que je vais partir sur un mixte des deux, l'avantage de la table c'est aussi de pouvoir faire d'autres choses.
Allez, vous ferez bien ce que je vais proposer, si c'est pas convaiquant, on passera bien entendu par le nouveau champ dans "_user_cache. Ou rectifier le tir...

coolsocks · 2006-11-16 05:43:08

J'ai mis en palce ce matin au réveil

C'EST SUPER

C'est exactement ce que je cherchais

Un GRAND merci à toi Rub

VDigital · 2006-11-16 05:59:22

rub a écrit:
On est bien sur la même longeur d'onde? ;-)

Oui.

Par contre, le code - très joli au demeurant - est loin de la solution finale, heureusement.
Bien joué, rub, une bonne leçon de coding avancé (mais quasiment non maintenable malheureusement).
8-)

PS: Ceux qui seraient tenté avec un grosse galerie (+ de 200 catégories), vous pouvez faire le test, et éventuellement prévoir le retour arrière.
Par contre, nous serions certainement tous très curieux d'avoir un retour sur le temps de réponse.

Piwigo.org

Annonce

#16 2006-11-15 15:14:35

Re: Notification de mise a jour

#17 2006-11-15 15:50:58

Re: Notification de mise a jour

rub a écrit:

z0rglub a écrit:

#18 2006-11-15 16:32:55

Re: Notification de mise a jour

VDigital a écrit:

z0rglub a écrit:

#19 2006-11-15 16:51:07

Re: Notification de mise a jour

rub a écrit:

rub a écrit:

#20 2006-11-15 17:43:45

Re: Notification de mise a jour

z0rglub a écrit:

rub a écrit:

z0rglub a écrit:

rub a écrit:

#21 2006-11-15 18:33:16

Re: Notification de mise a jour

#22 2006-11-15 18:42:07

Re: Notification de mise a jour

rub a écrit:

Code:

#23 2006-11-15 18:52:52

Re: Notification de mise a jour

z0rglub a écrit:

rub a écrit:

Code:

#24 2006-11-15 18:55:38

Re: Notification de mise a jour

#25 2006-11-15 19:06:21

Re: Notification de mise a jour

VDigital a écrit:

#26 2006-11-15 19:39:53

Re: Notification de mise a jour

#27 2006-11-16 00:10:24

Re: Notification de mise a jour

Code:

Code:

Code:

Code:

#28 2006-11-16 00:15:51

Re: Notification de mise a jour

z0rglub a écrit:

#29 2006-11-16 05:43:08

Re: Notification de mise a jour

#30 2006-11-16 05:59:22

Re: Notification de mise a jour

rub a écrit:

Pied de page des forums