2009-10-03 11 views
6

Quindi ho un'app che, se sono onesto, non ha realmente bisogno dell'integrità transazionale (molti aggiornamenti, nessuno dei quali è critico). Quindi stavo programmando di lasciare semplicemente i gruppi di entità sul ciglio della strada per ora. Ma mi piacerebbe ancora capirlo (provenendo da un background relazionale).Gruppi di entità nel datastore di Google App Engine

Il modo in cui lo vedo, tutte le query per la mia app saranno utente per utente. Pertanto, non è necessario raggruppare più in alto di un'entità utente, in base allo docs recommendations. Ma non stavo progettando di avere un'entità utente specifica, affidandomi invece a UserProperty nelle entità stesse.

Il modo in cui lo vedo, se voglio le transazioni (per utente), avrò bisogno di qualche tipo di entità utente root come genitore di tutte le entità che fanno parte della gerarchia dei suoi dati, non importa quanto sottile questa entità sarebbe in realtà cioè sostanzialmente senza proprietà.

È corretto?

Scuse per verboseness, ho veramente solo il ping quello schema-less in realtà significava in pratica stasera ...

risposta

3

si sono essenzialmente corretta. È necessario raggrupparli se si desidera funzionalità transazionali. Tuttavia, è possibile raggruppare più entità insieme senza creare un'entità root effettiva, nel senso di un'entità nel datastore. Si crea invece una sorta di entità radice virtuale. Un caso di utilizzo importante di questa funzione è la possibilità di creare un oggetto figlio prima di crearlo padre.

È possibile creare un soggetto con un percorso antenato senza prima creare la controllante. Per fare ciò, è necessario creare una chiave per l'antenato con e il nome della chiave, quindi utilizzarlo come il genitore della nuova entità. Tutte le entità con lo stesso antenato di radice appartengono a lo stesso gruppo di entità, indipendentemente dal fatto che la radice del percorso rappresenti un'entità effettiva .

Tale quota è da the same doc you linked to.

11

Il modo in cui lo vedo, se voglio le transazioni (per utente), avrò bisogno di qualche tipo di utente root come genitore di tutte le entità che fanno parte della gerarchia dei suoi dati, non importa quanto sia sottile questa entità, in pratica non è cioè proprietà.

Non vorrei creare solo un'entità utente root e lanciare tutto nel suo gruppo di entità. Pensa a cosa ti serve per le transazioni. Se non hai proprietà sulla tua entità utente, con che cosa le useresti nelle transazioni?

Non so i tuoi dati, ma supponiamo che sia un sistema di blog e tu abbia utenti, post e commenti. Il modello Post contiene un numero_di_commenti per cui non devi contarli. Si potrebbe desiderare che le transazioni garantiscano quando si crea un commento, la proprietà number_of_comments può essere aggiornata in modo sicuro.

In questo caso, sarebbe un overhead non necessario avere tutti gli utenti post e commenti in un singolo gruppo di entità. Invece, puoi pubblicare i commenti nello stesso gruppo di entità del post a cui appartengono. Non ci sarebbe bisogno di inserire i post nello stesso gruppo di un utente, e infatti questa sarebbe una cattiva idea, dato che i commenti pubblicati in qualsiasi post di un utente sarebbero in competizione per scrivere lo stesso gruppo di entità.

Ho scritto un short article about entity groups sul mio blog oggi. Potresti trovarlo utile

Problemi correlati