2012-08-25 8 views
11

Actualmente, gran parte de mi código hace un uso extensivo de antepasados ​​para poner y traer objetos. Sin embargo, estoy buscando cambiar algunas cosas.¿Usa antepasados ​​o propiedades de referencia en Google App Engine?

Inicialmente pensé que los antepasados ​​ayudaban a hacer consultas más rápido si sabías quién era el antepasado de la entidad que estás buscando. Pero creo que resulta que los antepasados ​​son principalmente útiles para el soporte de transacciones. No hago uso de transacciones, así que me pregunto si los antepasados ​​son más una carga en el sistema que una ayuda.

Lo que tengo es una entidad de usuario, y muchas otras entidades como say Comments, Tags, Friends. Un usuario puede crear muchos comentarios, etiquetas y amigos, por lo que cada vez que un usuario lo hace, configuro el ancestro para todos los objetos recién creados como el usuario.

Así que cuando creo un comentario, puse el antepasado como el usuario:

comment = Comment(aUser, key_name = commentId) 

Ahora, la única razón por la que estoy haciendo esto es estrictamente para la consulta de los propósitos. Pensé que sería más rápido cuando quisiera obtener todos los comentarios de un determinado usuario para obtener todos los comentarios con un antecesor común en lugar de consultar todos los comentarios donde authorEmail = userEmail.

Así que cuando quiero conseguir todos los comentarios de un determinado usuario, lo hago:

commentQuery = db.GqlQuery('SELECT * FROM Comment WHERE ANCESTOR IS :1', userKey) 

Así que mi pregunta es, ¿es un buen uso de los antepasados? ¿Debería cada comentario en su lugar tener una propiedad de referencia que haga referencia al objeto de usuario que creó el comentario y filtrar por ese?

(Además, mi pensamiento era que el uso de los antepasados ​​en lugar de un ReferenceProperty indizada, se ahorra en costes de escritura. ¿Estoy equivocada aquí?)

Respuesta

8

tienes razón en el costo de escritura, un antepasado es parte de la clave que viene "gratis". el uso de una propiedad de referencia aumentará su costo de escritura si la propiedad de referencia está indexada.
Dado que consulta en esa propiedad de referencia si será necesario indexarla.

Ancestro no solo es importante para las transacciones, en el HRD (la implementación predeterminada del almacén de datos) si no crea cada comentario con el mismo ancestro, las reglas no serán muy consistentes.

- Agregar comentario de Nick ---
Cada entidad con el mismo padre estará en el mismo grupo de entidades, y escribe a grupos de entidades son serializados, por lo que usar antepasados ​​aquí va a ralentizar las cosas si y sólo si usted está escribiendo múltiple entidades concurrentemente. Dado que todas las entidades de un grupo son 'propiedad' del usuario que forma la raíz del grupo en su instancia, esto no debería ser un problema, y ​​de hecho, lo que está haciendo es en realidad un patrón de diseño recomendado. .

+0

Pero, ¿los antepasados ​​me ralentizan en absoluto? Ya que brindan seguridad adicional al escribir, estoy seguro de que eso tiene algún costo, ¿no? Simplemente no sé qué opción elegir ... – Snowman

+0

Realmente no lo sé, pero creo que realmente no afecta la velocidad de la consulta ya que ese antecesor es parte de la clave y se usa (algunos qué) de cualquier manera al hacer una consulta. –

+1

Todas las entidades con el mismo elemento primario estarán en el mismo grupo de entidades y las escrituras en grupos de entidades se serializarán, por lo que el uso de ancestros aquí reducirá la velocidad si se escriben varias entidades al mismo tiempo. Dado que todas las entidades de un grupo son 'propiedad' del usuario que forma la raíz del grupo en su instancia, esto no debería ser un problema, y ​​de hecho, lo que está haciendo es en realidad un patrón de diseño recomendado. . –