Hi Hari, > I understood that > a. To achieve atomicity of update/delete of several entities we need > to do it in a transaction and hence all should fall under same entity > group > b. Having big entity groups is not scalable as it causes contention. > (Q1: Correct?)
Correct, but slim3, which is a java framework, supports global transactions between multiple entity groups. http://sites.google.com/site/slim3appengine/#gtx You may worry about the overhead of global transactions. Don't worry. It is not very expensive. The demonstration is as follows: http://slim3demo.appspot.com/gtx/ Yasuo Higa On Fri, Dec 3, 2010 at 7:53 PM, har_shan <harsha...@gmail.com> wrote: > Hello, > Am learning AppEngine and have started developing new app and want to > clarify something. > > I understood that > a. To achieve atomicity of update/delete of several entities we need > to do it in a transaction and hence all should fall under same entity > group > b. Having big entity groups is not scalable as it causes contention. > (Q1: Correct?) > > So here is an entity model of an online examination system for sake of > discussion: > > Entities: > Subject > Exam > Page > Question > Answer > > As you can see from top, each entity 1 - many relationship with the > immediate bottom one i.e 1 Subject can have many exams, 1 exam -> many > pages, 1 page can have many questions... > > As you can see, i would like to establish cascading update/delete > relationship among these entities (JPA datanucleus appengine > implemention supports this (under the hood) by putting all entities > under same entity group (Q2: Correct?) though AppEngine natively > doesn't support this constraint) so naturally all would go under same > entity group so that > a. i can delete a Page (if my user does) in a transaction and be sure > that all pages, questions, answers are all deleted > b. or i can delete a subject altogether in a transaction all clear all > stuff underneath it > > So when i extend this to my real app, i see that all of my (or atleast > most) entities are interrelated and fit into same entity group to be > able to transact them altogether - making my model inefficient. > > Q3: Please advice on how to rethink this design (and the best > practice) and still achieve what i need. Ask me more if needed. > Would be great if you could point me to relevant examples. > > p.s. 1 solution i could think of is having each entity in a separate > entity group and a separate persistent field in each entity (say Exam) > named 'IS_DELETED' defaulting to FALSE (value 0). Once a user deletes > an Exam, i will set the field to 1 (TRUE) and that i don't load them > anymore. I shall write a Cron job which clears all related entities in > separate separate transaction in the backend which will retry upon > failures if needed. But am sure this is not elegant and not sure > whether this will work out.. > > Thanks all for your responses, > Hari > > -- > You received this message because you are subscribed to the Google Groups > "Google App Engine" group. > To post to this group, send email to google-appeng...@googlegroups.com. > To unsubscribe from this group, send email to > google-appengine+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/google-appengine?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appeng...@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
