J'essaie d'envelopper mon esprit autour des groupes d'entités dans Google AppEngine. Je les comprends en général, mais comme il semble que vous ne pouvez pas changer les relations une fois que l'objet est créé ET que j'ai une grosse migration de données à faire, je veux essayer de le faire correctement la première fois.Google Appengine: Est-ce un bon ensemble de groupes d'entités?
Je crée un site d'art où les membres peuvent s'inscrire en tant que membres réguliers ou en tant que membre d'une poignée de types d'entités non polymorphes (artiste, lieu, organisation, représentant de l'artiste, etc.). Les artistes, par exemple, peuvent avoir Artwork, qui peut à son tour avoir d'autres relations (Galerie, médias, etc.). Toutes ces choses sont connectées via des références et je comprends que vous n'avez pas besoin de groupes d'entités pour faire simplement des références. Cependant, certaines des références doivent exister, c'est pourquoi je regarde les groupes d'entités. De la docs: "Une bonne règle pour les groupes d'entités est qu'ils doivent être de la taille d'un seul utilisateur ou moins."
Cela étant dit, j'ai quelques questions, oui/non.
Question 0: Je suppose que vous n'avez pas besoin de groupes d'entités pour effectuer des transactions. Cependant, étant donné que les groupes d'entités sont stockés dans la même région que Big Table, cela permet de réduire les problèmes de cohérence et les conditions de concurrence. S'agit-il d'un regard équitable sur les groupes d'entités et les transactions ensemble?
Question 1: Lorsqu'une entité enfant est enregistrée, les objets parents sont-ils implicitement accédés/sauvegardés? Par exemple, si je crée un groupe d'entités avec un chemin Membre/Artiste/Œuvre, si je sauvegarde un objet Artwork, les objets Membre et Artiste sont-ils mis à jour/accédés? Je ne pense pas, mais je suis juste sûr.
Question 2: Si la réponse à la question 1 est oui, est-ce que l'accès/la mise à jour ne fait que remonter le chemin et n'affecte pas les autres enfants. C'est-à-dire que si je mets à jour une œuvre d'art, aucun autre enfant d'illustration du membre n'est mis à jour. Question 3: En supposant qu'il est très important que le membre et son entité de type de compte associé existe lorsqu'un utilisateur s'inscrit et que seul l'utilisateur met à jour son entité de type de compte associé et membre, est-il sensé de mettre ces dans les groupes d'entités ensemble?
i.e. Membre/Artiste, Membre/Organisation, Membre/Lieu de résidence. De même, en supposant que seul l'utilisateur sera en mesure de mettre à jour les entités Artwork, est-il sensé de les inclure également? Note: Media/Gallery/etc qui sont des références à Artwork peuvent être liés à beaucoup d'œuvres d'art, pas seulement celles qui appartiennent à l'utilisateur (c'est-à-dire plusieurs à plusieurs relations).
Il est logique d'avoir tous les bits de l'utilisateur dans un groupe d'entités si cela fonctionne comme je le soupçonne (à savoir Q1/Q2 sont "non"), car ils seront tous dans la même région de BigTable. Toutefois, l'ajout de l'illustration au groupe d'entités semble être une violation du principe «Keep It Small» et, honnêtement, peut ne pas être dans les transactions hormis la sauvegarde de la bande passante/des retraits lorsque les utilisateurs téléchargent des images.
Des pensées? Suis-je en train d'approcher les groupes d'entités?
Merci beaucoup! Je pense que cela me donne un bon départ pour la mise en place de ma migration. –
Comment supprimer en lots? – corydoras