restrizioni sulle transazioni del datastore

Question

nella mia applicazione dell'app google, ogni volta che un utente acquista un numero di contratti, questi eventi vengono eseguiti (semplificati per chiarezza):

• user.cash è diminuito
• user.contracts è aumentato del numero
• contratti.current_price è aggiornato.
• market.no_of_transactions è aumentato di 1.

in un rdms, questi verrebbero inseriti nella stessa transazione. Ritengo che google datastore non consenta a entità di più di un modello di essere nella stessa transazione.

qual è l'approccio corretto a questo problema? come posso garantire che se una scrittura fallisce, tutte le scritture precedenti vengono ripristinate?

modifica: ovviamente ho perso gruppi di entità. Ora gradirei ulteriori informazioni su come vengono utilizzate. Un altro punto da chiarire è che Google dice "utilizzare i gruppi di entità solo quando sono necessari per le transazioni. Per altre relazioni tra entità, utilizza le proprietà ReferenceProperty e i valori chiave, che possono essere utilizzati nelle query ". significa che devo definire sia una proprietà di riferimento (poiché ho bisogno di interrogarli) sia una relazione genitore-figlio (per le transazioni)?

modifica 2: e infine, come posso definire due genitori per un'entità se l'entità viene creata per stabilire una relazione n-to-n tra 2 genitori?

Answer 1

Dopo una ricerca approfondita, ho scoperto che un livello di transazione distribuita che fornisce una soluzione alla restrizione del singolo gruppo di entità è stato sviluppato nell'area utenti con l'aiuto di alcune persone di Google. Ma finora, non è stato rilasciato ed è disponibile solo in Java.

Answer 2

Lasciami aggiungere un preventivo dalla Documentazione del datastore :

  

Una buona regola empirica per i gruppi di entità è che dovrebbero esserlo   la dimensione di un singolo utente di   dati o inferiori.

Potresti creare un'entità pseudo radice e mettere tutto al di sotto di questo. Quindi, esegui tutto in una transazione.

Answer 3

shanyu, hai menzionato il livello di transazione distribuita che ti consente di operare attraverso arbitrariamente molti gruppi di entità in una singola transazione. in realtà è stato rilasciato , semplicemente non è stato pubblicizzato a gran voce. è stato progettato e scritto da Daniel Wilkerson ed Erick Armbrust, con un po 'di consulenza da parte mia. dan lo descrive in questo discorso .

ha anche descritto nick johnson come fare " trasferire " digitare le operazioni tra gruppi di entità , in modo simile a quanto descritto. non è generico come la tapioca-orm, ma è più semplice e leggero.

esiste una funzione integrata correlata, attività transazionali , che consente di aggiungere un'attività a una coda all'interno di una transazione dell'archivio dati, in modo tale che venga aggiunta solo se la transazione viene eseguita correttamente. tale attività può quindi eseguire più operazioni di archivio dati, inclusa una transazione su un diverso gruppo di entità. non è forte come la soluzione di dan ed erick, ma ti garantisce la coerenza finale garantita tra i gruppi di entità, il che è abbastanza buono per molti casi d'uso, senza il sovraccarico extra.

in risposta alle tue domande: 1) non sei obbligato a utilizzare sia le proprietà di riferimento sia le relazioni padre / figlio (es. gruppi di entità). questa linea guida significa solo che i gruppi di entità limitano il throughput di scrittura del datastore, poiché le scritture sono serializzate per gruppo di entità. dovresti esserne consapevole se stai considerando di strutturare i tuoi dati in gruppi di entità solo per le query degli antenati.

2) un'entità non può avere più di un genitore. se si desidera modellare una relazione molti-a-molti, in genere è necessario utilizzare una proprietà ListProperty di proprietà di riferimento (ovvero chiavi). consulta questo articolo e questo discorso per i dettagli.