Une chose qui me vient à l'esprit ici est que vous n'aurez peut-être pas besoin de faire tout le travail que vous pensez devoir faire, et votre problème peut probablement être résolu avec un peu d'aide de Index TTL et éventuellement collections plafonnées . Considérez les entrées suivantes :
{ "_id" : ObjectId("531cf5f3ba53b9dd07756bb7"), "user" : "A", "units" : 50 }
{ "_id" : ObjectId("531cf622ba53b9dd07756bb9"), "user" : "B", "units" : 62 }
Il y a donc deux entrées et vous avez ce _id valeur de retour lorsque vous avez inséré. Ainsi, au départ, "A" n'avait personne contre qui jouer, mais l'entrée pour "B" jouera contre celle qui la précède.
Les ObejctId sont monotone , ce qui signifie que le "prochain" est toujours plus de valeur que la dernière. Ainsi, avec les données insérées, procédez comme suit :
db.moves.find({
_id: {$lt: ObjectId("531cf622ba53b9dd07756bb9") },
user: { $ne: "B" }
}).limit(1)
Cela donne le "mouvement" inséré précédent au mouvement actuel qui vient d'être effectué, et le fait parce que n'importe quoi qui a été précédemment inséré aura un _id avec moins de valeur que l'élément actuel. Vous vous assurez également que vous ne "jouez" pas contre le propre coup de l'utilisateur, et bien sûr vous limitez le résultat à un seul document.
Ainsi, les "mouvements" avanceront pour toujours, lorsque l'insertion suivante est faite par l'utilisateur "C", ils obtiennent le "mouvement" de l'utilisateur "B", puis l'utilisateur "A" obtiendra le "mouvement" de l'utilisateur "C ", et ainsi de suite.
Tout ce qui "pourrait" arriver ici, c'est que "B" fasse le suivant "déplacer" dans l'ordre, et vous récupéreriez le même document que lors de la dernière demande. Mais c'est un point pour votre conception de "session", pour stocker le dernier "résultat" et s'assurer que vous n'avez pas récupéré la même chose, et en tant que tel, gérez cela cependant vous voulez dans votre conception.
Cela devrait suffire à "jouer" avec. Mais passons à votre "suppression " partie.
Naturellement, vous "pensez" que vous voulez supprimer des choses, mais revenons à mes "assistants" initiaux, cela ne devrait pas être nécessaire. D'en haut, la suppression ne devient qu'un facteur de "nettoyage", de sorte que votre collection ne se développe pas dans des proportions massives.
Si vous avez appliqué un index TTL, de la même manière que ce tutoriel explique, vos entrées de collection seront nettoyées pour vous et supprimées après un certain laps de temps.
Aussi que peut-on faire, et surtout compte tenu du fait que nous utilisons l'augmentation nature du _id clé et qu'il s'agit plus ou moins d'une "file d'attente" par nature, vous pouvez éventuellement l'appliquer comme un collection plafonnée
. Ainsi, vous pouvez définir une taille maximale pour le nombre de "mouvements" que vous allez conserver à tout moment.
En combinant les deux ensemble, vous obtenez quelque chose qui ne "grandit" qu'à une certaine taille et qui sera automatiquement nettoyé pour vous, si l'activité ralentit un peu. Et cela va garder toutes les opérations rapides .
En fin de compte, la simultanéité de "supprime " qui vous inquiétait a été supprimé en "supprimant" en fait la nécessité de supprimer les documents qui viennent d'être lus. La requête reste simple, et l'index TTL et la collection plafonnée s'occupent de la gestion de vos données pour vous.
Voilà donc ce que je pense d'un jeu très concurrent de "Blind War".
