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 -~----------~----~----~----~------~----~------~--~---
