restrictions de transaction de banque de données

Question

dans mon application google, lorsqu'un utilisateur achète plusieurs contrats, ces événements sont exécutés (simplifiés pour plus de clarté):

• user.cash est diminué
• user.contracts est augmenté du nombre
• contracts.current_price est mis à jour.
• market.no_of_transactions est augmenté de 1.

dans les rdms, ceux-ci seraient placés dans la même transaction. Je conçois que le magasin de données Google n'autorise pas les entités de plusieurs modèles à être dans la même transaction.

quelle est la bonne approche à ce problème? comment puis-je m'assurer que si une écriture échoue, toutes les écritures précédentes sont annulées?

edit: J'ai visiblement manqué des groupes d'entités. J'aimerais maintenant avoir plus d'informations sur leur utilisation. Un autre point à clarifier est que Google indique "N'utilisez les groupes d'entités que lorsqu'ils sont nécessaires pour les transactions. Pour les autres relations entre entités, utilisez les propriétés ReferenceProperty et les valeurs Key, qui peuvent être utilisées dans les requêtes ". Cela signifie-t-il que je dois définir à la fois une propriété de référence (car j'ai besoin de les préciser) et une relation parent-enfant (pour les transactions)?

modifier 2: et enfin, comment définir deux parents pour une entité si cette entité est créée pour établir une relation n-à-n entre 2 parents?

Answer 1

Après des recherches approfondies, j'ai constaté qu'une couche de transaction distribuée offrant une solution à la restriction de groupe d'entités uniques avait été mise au point dans le pays de l'utilisateur avec l'aide de certaines personnes de Google. Mais jusqu'à présent, il n'est pas publié et n'est disponible qu'en Java.

Answer 2

Permettez-moi d'ajouter une citation tirée de la documentation sur le magasin de données. :

  

Une bonne règle générale pour les groupes d’entités est qu’ils devraient être sur   la taille de la valeur d'un utilisateur unique de   données ou plus petit.

Vous pouvez créer une entité pseudo-racine et tout mettre en dessous. Ensuite, vous exécutez tout dans une transaction.

Answer 3

shanyu, vous avez mentionné la couche de transaction distribuée qui vous permet d’opérer de manière arbitraire sur de nombreux groupes d’entités au cours d’une même transaction. en fait a été publié , il n'a tout simplement pas été annoncé très fort. Il a été conçu et écrit par Daniel Wilkerson et Erick Armbrust, avec quelques consultations de ma part. dan la décrit dans cette discussion .

nick johnson a également décrit comment procéder & transférer; " tapez des opérations sur des groupes d'entités , semblables à ce que vous décrivez. ce n’est pas aussi polyvalent que tapioca-orm, mais son poids est plus simple et plus léger.

il existe une fonctionnalité intégrée, tâches transactionnelles , qui vous permet d'ajouter une tâche à une file d'attente au sein d'une transaction de magasin de données, de telle sorte qu'elle ne sera ajoutée que si la transaction est validée avec succès. cette tâche peut alors effectuer plus d'opérations de banque de données, y compris une transaction sur un groupe d'entités différent. Ce n’est pas aussi solide que la solution de dan et erick, mais elle vous garantit une cohérence éventuelle entre les groupes d’entités, ce qui est suffisant pour de nombreux cas d’utilisation, sans la charge supplémentaire nécessaire.

En réponse à vos questions: 1) vous n'êtes pas obligé d'utiliser à la fois les propriétés de référence et les relations parent / enfant (c'est-à-dire les groupes d'entités). cette directive signifie simplement que les groupes d'entités limitent le débit d'écriture de la banque de données, car les écritures sont sérialisées par groupe d'entités. sachez que si vous envisagez de structurer vos données en groupes d'entités uniquement pour les requêtes des ancêtres.

2) une entité ne peut pas avoir plus d'un parent. Si vous souhaitez modéliser une relation plusieurs à plusieurs, vous devez généralement utiliser une propriété ListProperty de propriétés de référence (c.-à-d. clés). voir cet article et cette discussion pour plus de détails.