Google App Engine consulta HRD sin antecesor

Question

Tengo un proyecto GAE escrito en Java y tengo algunas ideas sobre el HRD y un problema que no estoy seguro de cómo resolverlo.

Básicamente tengo usuarios en mi sistema. Un usuario consiste en un ID de usuario, un nombre de usuario, un correo electrónico y una contraseña. Cada vez que creo un nuevo usuario, quiero verificar que no haya un usuario con el mismo ID de usuario (nunca debería haberlo), nombre de usuario o correo electrónico.

El ID de usuario es la clave, por lo que creo que hacer una con esto será consistente. Sin embargo, cuando realizo una consulta (y utilizo un filtro) para encontrar posibles usuarios con el mismo nombre de usuario o correo electrónico, no puedo estar seguro de que los resultados sean consistentes. Entonces, si alguien creó un usuario con el mismo nombre de usuario o correo electrónico hace un par de segundos, es posible que no lo encuentre con mi consulta. Entiendo que los antepasados ​​se utilizan para solucionar este problema, pero ¿qué sucede si no tengo un antepasado para utilizar para la consulta? El usuario no tiene un padre.

Estaría encantado de escuchar sus pensamientos sobre esto, y lo que se considera la mejor práctica en situaciones como estas. Estoy usando Objectify para GAE si eso cambia algo.

Answer 1

No recomendaría el uso del correo electrónico ni de ninguna otra clave natural para su entidad de usuario. Los usuarios cambian sus direcciones de correo electrónico y no desea terminar reescribiendo todas las referencias de claves externas en su base de datos cada vez que alguien cambia su correo electrónico.

He aquí una breve reseña de cómo puedo solucionar este problema:

https://groups.google.com/d/msg/google-appengine/NdUAY0crVjg/3fJX3Gn3cOYJ

crear una entidad EmailLookup separada cuya @Id es la forma normalizada de una dirección de correo electrónico (acabo en minúsculas todo - técnicamente incorrecto, pero ahorra mucho dolor cuando los usuarios capitalizan accidentalmente Joe@example.com). Mi EmailLookup se ve así:

@Entity(name="Email") 
public class EmailLookup { 
    /** Use this method to normalize email addresses for lookup */ 
    public static String normalize(String email) { 
     return email.toLowerCase(); 
    } 

    @Id String email; 
    @Index long personId; 

    public EmailLookup(String email, long personId) { 
     this.email = normalize(email); 
     this.personId = personId; 
    } 
} 

También hay un campo de correo electrónico (no normalizada) en mi entidad Usuario, el cual utilizo para enviar correos electrónicos salientes (preservar caso por si acaso es importante para alguien). Cuando alguien crea una cuenta con un correo electrónico en particular, cargo/creo el EmailLookup y las entidades de usuario con la clave en una transacción XG. Esto garantiza que cualquier dirección de correo electrónico individual será única.

La misma estrategia se aplica a cualquier otro tipo de valor único; Identificación de Facebook, nombre de usuario, etc.

Answer 2

Una forma de evitar el HRD eventual consistency, es usar get en lugar de query. Para poder hacer esto es necesario generar ID naturales, p. genere ID que consiste en datos que recibe a petición: correo electrónico y nombre de usuario.

Dado que get en HRD tiene una gran consistencia, usted podrá verificar de manera confiable si el usuario ya existe.

Por ejemplo una identificación legible naturales sería:

String naturalUserId = userEmail + "-" + userName; 

Nota: en la práctica, mensajes de correo electrónico son únicos. Entonces esta es una buena identificación natural por sí misma. No es necesario agregarle un nombre de usuario inventado.

Answer 3

También puede habilitar transacciones entre grupos (consulte https://developers.google.com/appengine/docs/java/datastore/overview#Cross_Group_Transactions) y luego, en una transacción, busque al usuario y cree uno nuevo, si eso le sirve.

Answer 4

Recomienda evitar un campo indexado y consultar a menos que tenga otros usos para él. Esto es lo que he hecho antes (Python) usando key_name (ya que los ID de la entidad deben ser enteros). Fácil de utilizar tanto el nombre_tecla o la identificación de otras entidades que tienen que enlaza con Usuario:

username = self.request.get('username') 
usernameLower = username.lower() 
rec = user.get_by_key_name(usernameLower) 
if rec is None: 
    U = user(
     key_name = usernameLower, 
     username = username, 
     etc...) 
    U.put() 
else: 
    self.response.out.write(yourMessageHere)