As far as I can tell, your plan should work -- I don't think you're missing
anything. Now that your design is set, I'm looking forward to hearing how
the actual implementation goes. Let me know if you have any other questions.
- Jason
On Tue, Sep 22, 2009 at 10:10 PM, Sam Walker <am.sam.wal...@gmail.com>wrote:
> 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) <apija...@google.com>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 <am.sam.wal...@gmail.com>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) <apija...@google.com>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 <am.sam.wal...@gmail.com>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
>>>>> <leszek.ptokar...@gmail.com>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 google-appengine-java@googlegroups.com
To unsubscribe from this group, send email to
google-appengine-java+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/google-appengine-java?hl=en
-~----------~----~----~----~------~----~------~--~---
