Thanks Jason, I realize that I wont be able to do transactions per say across the entity groups, and that the tasks can be run multiple times. With those two constraints in mind, I designed both of the tasks described above (running any of the two multiple times wont have any affect due to the stage variable/pendingSet, and they rely on transactions within the same entity group). Can you please take a deeper look on what the tasks actually do and will they achieve what I am trying to do here. Just want to make sure I am not missing anything basic with this.
Thanks for bringing out Option 3 as the easy winner with 30s rule I wasn't considering. Thanks for all your help in general as well! On Tue, Sep 22, 2009 at 10:39 AM, Jason (Google) <[email protected]>wrote: > Hi Sam. Based on your design above, I believe you're modeling an unowned > relationship between articles and reviewers, which makes sense. > Unfortunately, this means that you cannot use transactions, so you'll have > to work around this. Also keep in mind that tasks may be executed multiple > times so you will need to include logic to ensure that, should a task be > executed a second time, it won't throw off your application's state. > Regarding the task queue scenarios you laid out, I prefer the third option, > although the first and second should work. With the first and second > options, you need to be aware of how many articles and reviewers you're > processing since tasks are subject to the same 30-second request limits that > normal requests are. Option 3 neatly avoids this problem, which is one > reason why I consider it preferable. > > - Jason > > > On Sun, Sep 20, 2009 at 8:46 PM, Sam Walker <[email protected]>wrote: > >> Yea, I dont need to query on it, that's why I thought maybe storing in a >> HashMap would save me an extra query. Lets not go that way for now and >> assume I make a new relationship: >> >> I have another question, I was wondering if I can use TaskQueue to achieve >> some sort of transactions across entities and give my reviewers points (to >> rank them later on) based on their reviews. >> >> So, once an Article is finalized, I want to give each reviewer some points >> (based on some logic like first reviewer who approved gets the maximum >> points and so on and so forth), I am thinking of having another persistent >> variable in Article named stage, initialized to 0 and a pendingSet in >> Reviewer >> >> Once everyone approves, I can set stage to 1. >> >> Task 1: >> For all articles in stage 1: >> For all reviewers in this article >> in a transaction add the given article to pendingSet of the reviewer >> Set article stage to 2 >> >> Task 2: >> For all articles in stage 2: >> For all reviewers in this article: >> in a transaction, remove the article from the pendingSet and add >> points to the reviewer >> Set article stage to 3 >> >> First and foremost, you think this will work, right? >> >> Secondly, which approach is the best: >> 1. Make one big task which executes both task1 followed by task 2, and >> run it every five minutes or so. >> 2. Run both task 1 and task 2 every 5 minutes >> 3. Change the tasks so that they take the key of the article as input, and >> kick off Task 1 with key = articleKey after setting the stage to 1, and Task >> 1 kicks off Task2 with key = articleKey after setting the stage to 2. >> >> Please feel free to add more and advise which should be used when. >> >> Thanks a bunch! >> >> >> On Tue, Sep 8, 2009 at 12:03 PM, Jason (Google) <[email protected]>wrote: >> >>> How do you plan to use the HashMap? You won't be able to query on it, so >>> if that's a requirement, you'll want to look into adding another >>> relationship. >>> >>> - Jason >>> >>> On Fri, Sep 4, 2009 at 7:14 PM, Sam Walker <[email protected]>wrote: >>> >>>> Thanks! >>>> >>>> I am thinking of doing something like this: >>>> >>>> class Article { >>>> HashSet<Key> reviewers; >>>> HashSet<String> tags; >>>> int status; // pending, approved, declined - derived from reviewers' >>>> statuses >>>> >>>> HashMap<Key, Review> mapping; // Reviewer key to Review mapping to >>>> prevent storing making another 1:n relationship >>>> >>>> class Review { >>>> int status; // pending, approved, declined >>>> String notes; >>>> ... // anything else >>>> } >>>> } >>>> >>>> Do you think this will work? It doesn't get me all the things I want, >>>> but is still good enough I think (its kind of sad that we can't model this >>>> common scenario effectively/efficiently). >>>> >>>> Do you recommend doing this HashMap kind of a hacky thing or just make a >>>> new Entity and a new relationship? Is it worth the saving? >>>> >>>> >>>> On Sat, Aug 29, 2009 at 12:28 AM, leszek <[email protected]>wrote: >>>> >>>>> >>>>> Let consider a different approach. Take into account that Article and >>>>> Reviewer are rather immutable data (you need adding new article but >>>>> not to change existing), why break this nice feature. >>>>> Consider several classes: >>>>> Article { Key , {tags} .... next attribuites } >>>>> Reviewer { Key, mail, ... next attributes } >>>>> ArticleNotReviewedYet { Key articleKey } >>>>> ArticleUnderReview { Key articleKey, Key reviewerKey, int >>>>> reviewResult } >>>>> ArticleReviewed {Key articleKey, int totalReviewResult } >>>>> >>>>> This way if you want: >>>>> - to know the status of the article : find article in the first table >>>>> and find (by looking up the articleKey only) in what table >>>>> (ArticleNotReviewed, ArticleUnderReview, ArticleReviewed) contains the >>>>> articleKey >>>>> - to add new article: add article to Article and entry to >>>>> ArticleNotReviewed >>>>> - to start review: remove article from ArticleNotReviewed and add an >>>>> entry in ArticleUnderReview >>>>> - to add next review result: add next entry to ArticleUnderReview >>>>> - to end up review: remove all articleKey entries in >>>>> ArticleUnderReview and create entry in ArticleReviewed >>>>> >>>>> >>>>> Of course, it needs much more elaboration, but may be it is worth >>>>> considering. >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
