Ostatnio bawiłem się z silnikiem aplikacji Google i jego datastore i utworzyłem datamodel i relacje przy użyciu właściwości referencyjnych.Jaki jest cel przodków w magazynie danych wyszukiwarki Google?
Jednak nie mam pojęcia o koncepcji przodków w magazynie. Jaki jest ich cel i dlaczego powinienem z nich korzystać? W jaki sposób odnoszą się one do właściwości referencyjnych jednostek magazynu danych?
Inną korzyścią grup/przodków jednostek jest tworzenie wysp o silnej konsystencji (w przeciwieństwie do ostatecznej konsekwencji).
Na przykład możesz mieć projekt i jego zadania. Bez przodków możesz "zamknąć" zadanie, wrócić do ekranu listy zadań dla projektu i wykonać zapytanie dotyczące zadań otwartych. Zadanie, które właśnie zamknąłeś, nadal może się wyświetlać z powodu ostatecznej spójności. Zapytanie mogło zostać rozwiązane na serwerze, na którym aktualizacja nadal nie została zreplikowana.
Jednak z przodkami uzyskujesz silną konsystencję. Tak więc, zamiast prostego klucza obcego od zadania do projektu, czynisz projekt przodkiem zadań projektu. Teraz, podczas wysyłania zapytań o zadania, tworzysz zapytanie przodka, podając również klucz projektu. Wynik będzie silnie spójny, a zadanie, które właśnie zakończyłeś, nigdy nie będzie częścią wyniku.
Należy pamiętać, że używanie przodków nie jest wystarczające, aby zapewnić spójność. musisz także w razie potrzeby użyć transakcji ... – epeleg
Przykładem najczęściej używanym jest autor i ich książki.
Każda książka jest przechowywana w magazynie danych jako osobna jednostka, której nazwa i jej autor są przechowywane jako pola w modelu.
Jeśli chcesz znać wszystkie książki przez jednego autora, można uruchomić kwerendę tak, że
book.author == desired_author
Ale z przodków można również zapisać każdą książkę i ustawić model (nowy model autor) do czy to jest rodzic (to przodek).
Teraz możesz po prostu powiedzieć "pokaż mi wszystkie książki, które mają tego autora jako rodzica".
A raczej "pokaż mi wszystkie dzieci tego przodka", a wszystkie książki tego autora są zwracane.
Może się wydawać, że nie jest to użyteczne w tym przykładzie, ale jeśli wyobrazisz sobie zamiast "autora", masz "użytkownika", a zamiast "książki" masz "wiadomość na forum" i dziesiątki tysięcy wiadomości i nagle staje się bardzo przydatny, aby móc znaleźć wszystkie wiadomości według użytkownika (np. pokaż mi własne wiadomości).
https://developers.google.com/appengine/docs/python/datastore/queryclass#Query_ancestor
ancestor (ancestor)
Adds an ancestor filter to the query. The query will return only entities with the specified ancestor.
Istnieją również korzyści w zakresie kosztów dla znalezienia każdy rekord spodziewam.
co zrobić, jeśli książka ma wielu autorów? – varun
prawdopodobnie będziemy chcieli użyć właściwości list do przechowywania identyfikatorów w samej książce. –
Zapewnienie przodka powoduje, że twoja (nowa) encja jest częścią tej samej encji, co dostarczony przodek. W związku z tym wszystkie elementy z wspólnym obiektem głównym jako przodkiem są zapisywane w tym samym węźle danych, ta "lokalizacja" pozwala na wykonanie wielu działań na wszystkich tych jednostkach (w tej samej grupie podmiotów) w ramach transakcji. Następnie do każdego zapytania, które zawiera zapytanie przodka (takie jak zwracane są tylko elementy, które są potomkami zwykłego elementu głównego), działania te będą wyglądały tak, jakby miały miejsce jednocześnie (atomowo) lub wcale.
Ref: http://www2.mta.ac.il/~kirsh/download/MTA%20NoSQL%20Seminar/Lectures/GAE.pdf
Czy te pomagają?[tutaj] (http://stackoverflow.com/questions/1011814/storing-hierarchical-data-in-google-app-engine-datastore) i [tutaj] (http://stackoverflow.com/questions/2490261/what -does-ancestor-mean-in-the-google-app-engine-datastore) – StuartLC
Drugie ogniwo oświetlało. "Transakcje w GAE istnieją tylko w grupach przodków-potomków." Wydaje się więc, że jeśli chcę korzystać z transakcji, powinienem dbać o przodków. Moje makaroniki w datastore GAE nie są jeszcze tak zaawansowane, ale dobrze wiedzieć! – deltanine