Gérer deux types de joueurs : avec et sans inscription

[niahoo]

Hello,

Pour mon jeu, en plus d'une inscription classique (mail/password) (et par la suite via OpenID etc.) je souhaite que les gens puissent tester le jeu sans s'inscrire. L'idée est simplement de leur demander un nickname.

J'hésite entre deux solutions :

- Créer un utilisateur quand même, avec un flag temporary pour le supprimer. L'utilisateur est authentifié avec un cookie qui est supprimé si l'utilisateur se déconnecte. De temps en temps je supprime les utilisateurs en trackant la date de dernière connexion. Je peux choisir la durée du cookie (je penche pour le moment pour "infini" mais je souhaite quand même nettoyer la base de données donc je pense qu'au final le cookie sera valable X jours, renouvelés à chaque connexion). Si l'utilisateur aime le jeu, il lui est possible de compléter son inscription à tout moment. C'est bien car je peux gérer tous mes users de la même manière. Par contre, je dois soit (a) avoir le champ email à NULL, ce qui ne me plaît pas car la base de données n'aide plus à la validation des inscriptions, soit (b) mettre un fake mail dedans, ce qui me paraît bof car je dois alors gérer spécifiquement ces mails.

- Sinon je pensais à créer un autre modèle Guest, géré indépendamment des User. L'utilisateur peut quand même s'inscrire par la suite en gardant sa progression, je ne crée son vrai compte qu'à ce moment là. On garde le même mécanisme de cookies. Ici le problème est que je dois avoir deux règles de gestion dans tous mes controlleurs, checker si c'est un utilisateur ou un invité pour trouver infos et les mettre à jour. Je crois que c'est la moins bonne solution.

Peut être en existe-t'il d'autres, qu'en pensez-vous ?

[Ter Rowan]

moi je dirais la solution 1, avec e mail à null et du coup tu peux même virer le champ "temporary", puisque email==null te donne la réponse du temporary == true

le fake mail ne va rien t'apporter, ca ne permettra pas à la bdd d'aider à valider l'inscription (pour reprendre ton terme), donc ca fera exactement comme null sauf qu'il te faudra le temporary du coup

et pour aller plus loin, ce terme "aider à valider l'inscription" me perturbe un peu dans le sens où tu acceptes une inscription sans email (même temporaire) donc le fait d'avoir un mail n'apporte rien pour ta validation (ou bien j'ai pas compris) ca aide plutôt à supprimer un joueur plus vite si pas complètement inscrit (complet au sens avec tout indiqué)

[niahoo]

"aider à valider" c'est juste que tu peux profiter de la contrainte d'unicité sur ta colonne au lieu de le faire en code. mais bon oublie ça c'est pas le plus important .)

[Argorate]

ter rowan +1.

Ça évite de complexifier le code en rajoutant un cas particulier qui n'en ai pas un.
Surtout que si on fait bien les choses, le compte User, et le personnage Joueur sont deux choses distinct, du coup tu dois créer un personnage avec un pseudo.
Par contre il sera lié à un compte qui n'a pas encore de mail.

[niahoo]

Non je n'ai pas de personnage différent du compte utilisateur.

[niahoo]

Bon je suis un peu surpris, je pensais que plus de monde ici avait déjà résolu ce problème. Je vais donc partir sur ma première solution, merci pour vos réponses.

[Sephi-Chan]

Moi j'ai pas trop compris le problème en fait.
Tu n'aimes pas la solution de l'email NULL parce qu'il t'empêche de mettre une contrainte NOT NULL sur ta colonne ?

[niahoo]

Il empêche de mettre un NOT NULL mais surtout il empêche de mettre un UNIQUE (edit: en fait non sur Postgres c'est bon). Mais ce n'est pas vraiment que je n'aime pas. J'espérais plutôt qu'on me file une tierce technique plus simple et plus sympa ou plus maligne.

[Xenos]

Genre laisser l'e-mail vide ('', empty string)?
A défaut, le remplir avec une chaine spéciale qui n'est pas un mail valide, type "@@".

[niahoo]

Oui mais ça ok, c'est la solution 1. Le reste ce sont des détails d'implémentation. D'ailleurs comme le disait Ter Rowan je préfère NULL que mettre autre chose car ça a plus de sens ... à mon sens. Le concept de base de cette solution c'est d'utiliser le même modèle pour les joueurs enregistrés et les invités (Plu précisément, les invités héritent du modèle user de base).

La solution 2 est d'avoir deux modèles distincts, mais c'est plus encombrant qu'autre chose.

Voilà et après je ne vois pas ce qui pourrait être plus malin. Bon c'est pas bien grave, ça a l'air de bien fonctionner.