standard - En Google App Engine, ¿cómo puedo trabajar con consistencia eventual en el manejo de envíos de formularios?

google app engine standard environment

Question

Me he dado cuenta de que, con la coherencia final, el flujo de trabajo de procesamiento de formularios común al que estoy acostumbrado (enviar -> crear / actualizar registro -> redirigir -> volver a cargar) no funciona. Tras la redirección, el nuevo registro (probablemente) no estará disponible para su visualización. ¿Cómo debo manejar los formularios para que las actualizaciones se muestren al volver a cargar?

Podría intentar usar una coherencia sólida, pero como indica la documentación de App Engine , las actualizaciones están limitadas a una actualización por segundo .

Entonces, ¿cómo puedo procesar un formulario que proporciona retroalimentación inmediata del usuario con una posible coherencia?

Answer 1

Intenta reestructurar tu código para que obtengas la clave (que siempre te brinda los datos más recientes) en lugar de hacer una consulta. Me doy cuenta de que esto no siempre es posible, pero les daré un ejemplo reciente de algo que funcionó para mí.

Tengo un panel de usuario donde un usuario puede crear y eliminar "elementos". Mis entidades se veía así:

class User(ndb.Model)
    ...

class Item(ndb.Model)
    user = ndb.KeyProperty(User, required=True)

En el pasado, hacía una consulta como esta cuando respondía a una solicitud GET para el tablero del usuario.

items = Item.query(user=user.key)

Esta fue una mala experiencia porque un usuario eliminaría un elemento y después del POST / redirigir / OBTENER, el elemento recién eliminado volvería a aparecer en el panel debido a la coherencia final.

Para solucionar esto, cambié mi entidad de usuario para tener una lista de elementos como este:

class User(ndb.Model)
    items = ndb.KeyProperty(repeated=True)
    ...

Ahora, cuando muestro el tablero, hago esto:

items = ndb.get_multi(user.items)

Como ahora obtengo la clave, los datos están siempre actualizados.

Esto funciona para mí porque un usuario no tendrá tantos elementos. Sin embargo, si un usuario pudiera tener miles de elementos, este enfoque no funcionaría debido al límite de tamaño de la entidad.

Answer 2

Probablemente aún pueda usar consistencia sólida, siempre que diseñe sus grupos de entidades de manera adecuada. Leyendo de cerca el documento vinculado, la restricción es en realidad solo una actualización por segundo por grupo de entidades .

Esto se debe a que el protocolo de coherencia sin núcleo subyacente de Google ("Paxos") garantiza una coherencia sólida solo cuando se trabaja dentro de un grupo de entidades (se define como un grupo completo de claves, bajo una clave raíz e incluyendo esa clave raíz, donde el eventual padre -root keys es esa clave raíz - vea Transacciones y grupos de entidades para más información).

Quoth el manual:

Como se mencionó anteriormente, un grupo de entidades es un conjunto de entidades conectadas mediante ancestros con un elemento raíz común . La organización de datos en grupos de entidades puede limitar qué transacciones se pueden realizar:

... [detalles sobre transacciones] ...

• Hay un límite de rendimiento de escritura de aproximadamente una transacción por segundo dentro de un único grupo de entidades . Esta limitación existe porque Datastore realiza una replicación síncrona sin maestro de cada grupo de entidades en un área geográfica amplia para proporcionar una alta fiabilidad y tolerancia a fallas.

Por lo tanto, si diseña las claves del Almacén de datos para usar, por ejemplo, el ID del usuario registrado o la dirección de correo electrónico como clave principal, la lectura de la clave resultante en el otro extremo puede garantizarse consistentemente al especificar esa clave como ancestro.

También vale la pena señalar que una entidad no debe existir técnicamente en esa clave principal; solo necesita una clave para iniciar la raíz de su grupo de entidades, de modo que pueda aplicar su garantía de coherencia.

Si puede diseñar de esa manera, puede garantizar la coherencia y aplicar escrituras a razón de uno por segundo por usuario, o cualquiera que sea el alcance de sus claves.

Para obtener más información, consulte "Estructuración para una consistencia fuerte" .