Question de conception: Comment voulez-vous concevoir un événement récurrent système?
Si vous avez été chargée de construire un événement système de planification qui ont soutenu des événements récurrents, comment le feriez-vous? Comment gérez-vous lorsqu'un événement récurrent est retiré? Comment pourriez-vous voir quand les événements futurs qui va arriver?
c'est à dire Lors de la création d'un événement, vous pouvez choisir "répéter tous les jours" (ou hebdomadaire, annuelle, etc).
Une conception par réponse s'il vous plaît. Je suis habitué à Ruby/Rails, mais utiliser ce que vous voulez exprimer la conception.
M'a demandé lors d'une interview, et ne pouvait pas venir avec une très bonne réponse que j'ai aimé.
Remarque: a déjà posé la question/réponse ici. Mais j'espérais avoir plus de détails pratiques, comme détaillé ci-dessous:
- S'il était nécessaire d'être en mesure de commenter ou sinon ajouter des données à une seule instance de l'événement récurrent, comment cela fonctionnerait-il?
- Comment événement modifications et suppressions de travail?
- Comment calculez-vous lorsque des événements futurs se produisent?
- J'adore cette question, mais je suppose qu'il en sera fermé.
- Hey, j'ai le même problème, pouvez-vous s'il vous plaît ajouter vos recommandations et un lien sur votre git solution en réponse de la partie!? Je crois que vous avez résolu ce problème. Je suis intéressant dans le modèle de données en général. Merci
Vous devez vous connecter pour publier un commentaire.
J'ai commencé par la mise en œuvre de certaines expression temporelle comme décrit par Martin Fowler. Cela prend soin de déterminer quand une prévue élément doit effectivement se produire. C'est un moyen très élégant de le faire. Ce que j'ai est juste une accumulation de ce qui est dans l'article.
Le problème suivant a été de comprendre comment dans le monde pour stocker les expressions. L'autre problème, c'est quand vous lisez l'expression, comment ils s'insèrent dans une dynamique de l'interface utilisateur? On parlait juste de la sérialisation les expressions dans un BLOB, mais il serait difficile de marcher de l'arborescence d'expression pour savoir ce que signifie il.
La solution (dans mon cas) est de stocker les paramètres qui correspondent à un nombre limité de cas, l'Interface Utilisateur de soutien, et à partir de là, utiliser cette information pour générer les Expressions Temporelles à la volée (peut sérialiser lors de la création d'optimisation). Donc, le Calendrier de la classe finit par avoir plusieurs paramètres comme l'offset, la date de début, date de fin, le jour de la semaine, et ainsi de suite... et de ce que vous pouvez générer le Temporel des Expressions pour faire le travail.
Que pour avoir des instances des tâches, il y a un "service" qui génère des tâches pour N jours. Puisque c'est une intégration à un système existant et de toutes les instances sont nécessaires, cela fait sens. Cependant, une API comme cela peut facilement être utilisé pour projeter les récidives sans stocker toutes les instances.
J'ai dû le faire avant, quand j'étais la gestion de la base de données à la fin du projet. J'ai demandé à ce que chaque cas être stockés comme des événements distincts. Cela vous permet de supprimer un événement ou vous pouvez déplacer une plage. C'est beaucoup plus facile à enlever multiples que d'essayer de modifier un seul événement et de le transformer en deux. Nous étions alors en mesure de prendre une autre table qui a tout simplement eu un recurrenceID qui contient les informations de la récurrence.
@Joe Van Dyk a demandé: "Pourriez-vous regarder dans l'avenir et de voir quand les événements à venir serait?"
Si vous voulais voir/affichage la prochaine n les occurences d'un événement qu'ils auraient soit a) être calculée à l'avance et stocké dans un endroit ou b) être calculé à la volée et l'affiche. Ce serait la même pour toute soirée cadre.
L'inconvénient est qu'il vous faudra pour y mettre une limite quelque part et après que vous avez pour l'utilisation de b). Plus facile à utiliser b) pour commencer.
Le système de planification n'a pas besoin de cette information, il a juste besoin de savoir quand le prochaine événement.
Lors de l'enregistrement de l'événement, je voudrais enregistrer la planification d'un magasin (nous allons l'appeler "Horaires" et je voudrais calculer lorsque l'événement a été le feu à la prochaine fois et enregistrer ainsi, par exemple, dans "Événements". Ensuite, je regarde dans "Événements" et la figure la date du prochain événement était de prendre place et d'aller dormir jusqu'alors.
Lorsque l'application "se réveille" il serait à calculer lors de l'événement devrait avoir lieu encore une fois, les stocker dans "Événements" à nouveau, puis effectuez l'événement.
Répéter.
Si un événement est créé pendant le sommeil le sommeil est interrompu et recalculé.
Si l'application est de commencer ou de récupération à partir d'un sommeil événement ou similaire, cochez la case "Événements" pour les événements passés, et agir en conséquence (selon ce que vous voulez faire avec les événements manqués).
Quelque chose qui serait flexible et de ne pas prendre inutilement des cycles de PROCESSEUR.
Sur le dessus de ma tête (après la révision d'un couple de choses tout en tapant/pensée):
Déterminer le minimum de la récidive-la résolution nécessaire; c'est pourquoi, souvent, l'application s'exécute. C'est peut-être quotidien, peut-être toutes les cinq minutes.
Pour chaque événement récurrent, magasin le plus récent de l'exécution, l'exécution de l'intervalle et d'autres goodies comme des temps d'expiration si c'est souhaitable.
Chaque fois que l'application s'exécute, il vérifie tous les événements, en les comparant (aujourd'hui/maintenant + recurrenceResolution) à (recentRunTime + runInterval) et si elles coïncident, le feu de l'événement.
Quand j'ai écrit une application de calendrier pour moi mumble il y a des années, en gros, j'ai juste volé le mécanisme de planification à partir de cron et utilisé que pour des événements récurrents. par exemple, quelque Chose ayant lieu le deuxième samedi de chaque mois sauf en janvier comprendrait l'instruction "repeat=* 2-12 8-14 6" (tous les ans, les mois 2-12, la 2ème semaine s'étend du 8 au 14, et 6 pour le samedi parce que j'ai utilisé basée sur 0 numérotation pour les jours de la semaine).
Tout cela le rend assez facile de déterminer si l'événement se produit à une date donnée, il n'est pas capable de traiter "tous les N jours" récidive et est aussi un peu moins intuitif pour les utilisateurs qui ne sont pas unix-savvy.
De traiter des données uniques pour chaque événement les instances et l'enlèvement ou de rééchelonnement, j'ai juste gardé la trace de la distance des événements ont été calculés et stockés les événements qui en résultent dans la base de données, où ils peuvent alors être modifié, déplacé ou supprimé sans affecter l'original événement récurrent de l'information. Lorsqu'un nouvel événement récurrent a été ajouté, toutes les instances ont été immédiatement calculé jusqu'à ce que l'existant "dernier calculée de date".
Je ne prétends pas que c'est la meilleure façon de le faire, mais il est un façon, et qui fonctionne assez bien dans les limites je l'ai mentionné plus tôt.
Si vous avez un simple événement récurrent, tels que les quotidiens, hebdomadaires ou quelques jours par semaine, quoi de mal avec l'aide de buildt planificateur/cron/à fonctionnalités? Création d'un exécutable/console application et définir jusqu'à quand pour le faire fonctionner? Pas compliqué, calendrier, événement ou la gestion du temps.
🙂
//W