Yes, understood. Thanks. Am just trying my best to keep entities in isolation unless am really forced to group them. There is this use case in my example: User while creating a Exam, will create, edit, delete any Page, Question, Answer as they wish. At regular intervals, say 1 min, i will persist all changes. At this time, i can be successful in persisting a Page but unsuccessful in some Question/Answer (say) So i will just retry failed ones at next save. I just don't want to put all Page, Question, Answer is same entity group and fail the save altogether if a particular entity save is failed - just to maintain integrity of each save. Makes sense - atleast for my example?
Also what about my relationship mentioned in my prev post? Thanks again. On Dec 18, 11:53 am, Didier Durand <[email protected]> wrote: > Hi, > > The most important thing to remember to design your objects and their > relationship is the entity group: you cannot touch (update, delete, > create) entities belonging to more than 1 group in a single > transaction (unless you then use transaction-bound tasks) > > So, keep this point in min when you maximize the number of entity > groups by keeping entities in separate groups: it will make your > transactional code a little bit harder to develop if you want to > maintain database integrity. > > regards > > didier > > On Dec 17, 7:43 pm, har_shan <[email protected]> wrote: > > > > > > > > > i want to hear the best practice on establishing entity relationships in my > > case- > > > Example, for sake of discussion:- > > User > > Exam > > Page > > Question > > Answer > > > As you can see, from top, each entity has 1 - many relationship with entity > > immediately beneath it. > > Interesting case is a User can have any number of Exam and it can *scale* in > > whatever manner, but a Exam usually will have few Pages, > > a Page with few Questions, Questions with few Answers > > > I saw this interesting post > > best practice to persist medium-large > > data<http://www.mail-archive.com/[email protected]/ms...> > > > (which is also a answer to this ques) and it made me to design like this: > > Also i plan to keep each entity in its own entity group, as recommended by > > AppEngine - totally eliminating Parent relationship, as far as possible > > > class User{ > > String name; > > // List<Key<Exam> exams; NOT a good idea, as this will unnecessarily load > > bulk amt of Exam keys when i load User > > ... > > > } > > > So i would use a query to get all Exams created by any User. Fine. But > > > class Exam{ > > String subject; > > // With this i can *quickly* retrieve all Pages with keys, but as Exam and > > Page are not in same Entity Group, > > // how do i maintain *consistency* when, say, i delete a Page and > > accordingly remove that Key entry in Exam. > > // Also as said earlier, no. of pages (hence keys) shouldn't be too high, so > > dont need to worry abt size > > List<Key<Page> pages; > > > } > > > class Page{ > > String pageNo. > > Key<Exam> exam; // with this i can *only(?)* use query to get all Pages > > under a Exam, so *unnecessary index scan*[1] > > List<Key<Question> questions; > > > } > > > The same extends to Page -> Question -> Answer > > > [1] Retrieving via Keys are faster than > > querying<http://www.mail-archive.com/[email protected]/msg3384...> > > > So what is your recommendation and why? > > I can suspect that it should be a trade-off between unnecessary loading of > > keys/extra scan of indices but want to get some thoughts and what about > > consistency? > > > Thanks much in advance. > > p.s. though not relevant, most likely i will use low level framework, mainly > > Objectify.. -- You received this message because you are subscribed to the Google Groups "Google App Engine for Java" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
