Re: [sympa-fr] Type de données pour bounce_score_subscriber

[Sylvain Amrani <adresse@cachée>]

Olivier Salaün - CRU a écrit :

de 250 adresses qui dépassent les 50 caractères. Et je devrais encore ajouter des qualificatifs et autoriser les recipient delimiters '+' pour éviter de multiplier des boites... 

Vous faites référence aux champs de type email de la base ?
Rencontrez-vous des limitations avec d'autres champs ?

Les limitations sont sur les champs de type email, et les champs de type nom de liste.

Le changement automatique de la base est destiné à simplifier la vie des administrateurs. Je pense que c'est une fonctionnalité très utile.
Par contre nous pouvons ajouter un paramètre global permettant de désactiver cette fonctionnalité, afin de respecter des personnalisations éventuelles.

On pourrait mettre le %db_struct dans un db_schema.pl et rechercher le fichier source dans les répertoires habituels --ETCBINDIR-- comme pour les templates ?

Pouvez-vous préciser vos craintes et vos volumes.
A titre d'exemple, notre serveur gère 150 000 abonnés sans pb.
Nous connaissons des sites utilisant sympa pour des listes de 700 000 abonnés, d'autres 20 000 listes.

Mes craintes provenaient d'expressions comme REVERSE(SUBSTRING(user_subscriber FROM position('\@' IN user_subscriber) FOR 50)); et du temps d'environ 5 secondes entre 2 sync_include() en mise à jour de listes basées sur un filtre ldap (1 seconde environ pour le filtre lancé seul) alors que je n'ai pour l'instant "que" 5000 listes et 400.000 entrées dans la subscriber_table ; mais j'aimerais pouvoir aller vers du 10.000/1.000.000. Comme vous le voyez, j'ai plus de listes qu'elles ne sont grosses.

A regarder les logs, j'ai l'impression que sympa se débrouille mieux avec énormément d'utilisateurs plutôt qu'énormément de listes. Wwsympa peut répondre bizarrement. Par exemple, si je demande la liste des listes ou bien mes abonnements et qu'il y a beaucoup de réponses (quelques milliers), j'obtiens quelques fois un fil RSS vide (alors que je navigue) ou une erreur 500. Il semblerait que les FOREACH de tt2 font des foreach et non des while (list() = ) ce qui fait qu'on charge toujours tout en mémoire.
En revanche, quand je travaille sur les utilisateurs d'une grosse liste, j'obtiens des tableaux bien paginés et tout est fluide.
En fait cela peut rester secondaire, car il suffit de refaire les interfaces utilisateurs grâce aux interfaces SOAP.

Par ailleurs, chaque clic sur l'interface CGI valide le schéma base de données !

@++
Sylvain.