2010-09-13 17 views
2

Hypothèses: 1) Google AppEngine a le concept de groupes d'entités. 2) Les entités d'un groupe d'entités forment un arbre. Cependant, autant que j'ai compris, chaque put() à n'importe quelle entité dans cet arbre verrouillera l'arbre entier (pas seulement le parent immédiat) pendant un moment. 3) Les utilisateurs sont autorisés à écrire ca. 5 fois par secondes à l'arbre. 4) Il n'y a aucun moyen d'avoir un comportement non-verrouillable (c.-à-d. En faisant des propriétés non-indexées)Puis-je bénéficier des relations parent-enfant sans le coût de la contention de banque de données?

Serait-ce une bonne idée de créer mon propre modèle parent-enfant qui n'utilise pas le built-in Les fonctions-clés (comme celles-ci créeraient des groupes d'entités) mais utilisent plutôt des convétions snytax que j'ai inventées? Cela me permettrait de récupérer une entité "enfant" via une requête calculer la clé parente.

Répondre

4

La relation ancêtre utilisé par des groupes d'entités peut être modélisé dans votre propre code en utilisant une liste de références/clés aux entités mères. Les entités racines n'en auront aucune, les enfants des racines n'auront que l'entité racine dans leur liste, leurs enfants auront la racine et leur parent immédiat, et ainsi de suite. C'est ainsi que les ancêtres sont implémentés dans App Engine à des fins d'indexation, et cela vous permettra de faire les mêmes sortes de requêtes.

+0

Pourrais-je améliorer votre suggestion en mettant en plus une structure dans la façon dont je crée mes noms de clés? C'est à dire. encoder le parent-path directement dans le nom de la clé elle-même? Cette idée est-elle intelligente ou mauvaise? – xamde

+0

Vous pourriez le faire, oui. Tant que vous utilisez un délimiteur approprié, vous pouvez alors faire des demandes de plage sur une plage de noms de clé pour trouver tout avec un ancêtre donné. –

+0

Le livre "Programmation de Google App Engine, Dan Sanderson, O'Reilly" mentionne des cas où l'index n'est pas mis à jour correctement et manque des données qui sont dans le magasin mais devraient être dans l'index. Dans ces cas, les enfants nous manqueraient. Y a-t-il un moyen de contourner cela? Ou en d'autres termes: Les requêtes de plage sur les clés s'exécutent-elles sur les index ou dans les clés stockées dans le magasin de données lui-même? (Nous recherchons désespérément un moyen performant et fiable d'avoir un ensemble (potentiellement très grand) d'objets enfants pour un objet parent donné) – xamde

1

Vous pouvez utiliser une propriété de référence:

class Parent(db.Model): 
    x = db.IntegerProperty() 

class Child(db.Model): 
    parent = db.ReferenceProperty(
     reference_class = Parent, 
     collection_name = 'children') 
    y = db.IntegerProperty() 
+0

Désolé, je viens du monde Java en utilisant seulement l'API de bas niveau. J'ai un peu de mal à traduire votre exemple Python. Essentiellement, vous donneriez aux entités "Parent" et "enfant" un numéro de clé supplémentaire (x et y). Et vous stockez dans chaque parent une liste de ses enfants? Cela ne serait pas au-delà de 5000 enfants. – xamde

+0

Pourquoi introduisez-vous de nouveaux identifiants (x et y) ou s'agit-il simplement d'exemples pour des types de données dans vos exemples d'entités? – xamde

+0

Le stockage d'un ID du parent dans chaque enfant serait plus évolutif mais souffrirait de certains problèmes de concurrence (datastore et index non mis à jour dans une opération atomique, entraînant parfois du contenu dans la banque de données et pas dans l'index mais pas dans magasin de données). – xamde