Discussion :

[Arkante]

Bonjour,

Je suis en train de designer une application qui doit envoyer des notifications périodiques.

Je vais créer un CRON job qui va exécuter chaque minute un script PHP qui va chercher dans une base de données les notifications à envoyer :

1. Connection à la DB pour trouver les notifications
2. Mettre un flag ou déterminer la prochaine date pour chaque notification
3. Envoyer les notifications

Je voudrais savoir si vous avez des recommandations pour la syntaxe des notifications périodiques ou s'il existe une librairie qui gère ca. Pour illustrer le problème, prenons une notification envoyée toutes les heures.

Quel format adopté pour signifer le "toutes les heures". Existe-t-il quelque chose qui permet de comparer l'heure actuelle avec ce format ?


Si vous avez des idées je suis preneur. Merci d'avance.

[gene69]

C'est bizarre ta question. Tu veux utiliser cron comme "lanceur de tache plannifiée" la seule chose à faire c'est de lui donner le point d'entrée du script et de lui donner la bonne fréquence d'exécution.

Tu auras donc deux scripts ou un script avec des paramètres différents, ou deux scripts différents mais qui chargeront des bibliothèques communes, l'un qui s'execute toute les minutes (et donc qui est dure moins d'une minute ) l'autre qui est executé toutes les heures et qui n'est pas pertubé par l'action des scripts à la minute.

Décharge toi de la gestion du temps sur ton lanceur de tache. Du coup la syntaxe sera celle de CRON dans ton exemple

Pour le coté notification s'il s'agit d'une notification à un humain, par l'intermédiaire d'un mail.... d'abord il ne va jamais les lire parce qu'il y en aura trop il ne faudrait notifier que les évènements exceptionnels (indisponibilité serveur par exemple) mais dès que ceux-ci sont détectés et non lors d'une routine planifiée et encore une seule fois.

Pour ce genre de travaux, un log est bien mieux, s'il est bien dimensionné. Tu as des moteurs MySQL a disposition et des options d'insertions qui promettent des choses interessantes pour celà, sinon un bête syslog...

[Arkante]

Bonjour,

Je te remercie pour ton aide mais ma question ne porte pas sur la Business Logic qui est parfaitement adaptée aux besoins du projet. Je ne reviens donc pas sur ton avis sur les mail et log.

Je vais cependant éclaircir un point qui n'était peut-être pas clair dans mon précédent post.

L'utilisateur choisit ses notifications en fréquence avec comme précision la minute. Les possibilités, bien que dénombrables, sont trop nombreuses pour faire l'objet de CRON job séparés. Il ne serait pas pertinent d'écrire des milliers de lignes dans le CRONTAB.

[Arkante]

Bonjour,

Voici la solution que je vais appliquer, si ca peut aider qqu'un dans le futur :

1. Créer une table pour les notifications avec un champ "cron" (syntaxe cron pour la fréquence) et un champ "next" (prochaine fois que l'on doit notifier)
2. Toutes les minutes, je fetch les notifications ou "next" est proche de time()
3. Je calcule avec un CRON Parser la prochaine date et update "next"

[Joker-eph]

J'ai du mal à voir ce qu'il y a de vraiment compliqué en fait : un champ date_time ou timestamp ne fait pas l'affaire ?

Le CRONPARSER me semble compliqué non ?

Pour chaque notification configurée, tu enregistres l'intervalle souhaité dans un champs "interval" et l'heure/minute de la prochaine mise à jour dans un champ "prochaine_maj".

Toutes les minutes, tu fetch les notifications pour prochaine_maj < NOW(); et tu update prochaine_maj en ajoutant l'interval en minute avec les fonctions de DATE de mysql.

[Arkante]

En effet cette solution marche si les intervalles sont fixes. La syntaxe CRON permet de créer des fréquences à intervalles variables.

Par exemple : notification lundi et mardi chaque semaine. L'intervalle de lundi à mardi est différent de celui de mardi à lundi. Ta proposition ne marche pas.

Encore une fois, je n'ai pas expliqué toute la Business Logic mais il y a des raisons pour lesquelles j'ai fait ces choix.