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 wrote:
> Thanks
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 stag
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
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
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 wrote:
> Thanks!
>
> I am thinking of doing something like this:
>
> class Article {
> Has
Thanks!
I am thinking of doing something like this:
class Article {
HashSet reviewers;
HashSet tags;
int status; // pending, approved, declined - derived from reviewers'
statuses
HashMap mapping; // Reviewer key to Review mapping to prevent
storing making another 1:n relationship
clas
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 at
This would work, although there is a lot of redundancy as you say. A couple
of other ideas I have:
- Include the article status field in the Review itself -- this will be
redundant too, but at least you're only duplicating one field and not the
entire object. When you update an article's
Sorry, let me write it down with keys just to make sure we are on the same
page:
Article {
HashSet reviews; // Keys of reviews
HashSet tags;
int status; // derived from all Reviews' statuses.
}
Review {
Key article;
Key reviewer;
int status;
}
Reviewer {
String email;
}
Now, do yo
Yes, it is a key. I just wanted to make it obvious which Keys are involved.
I read the Embedded class as well, its not what I want here I think.
How would you model this scenario then? Both models I discussed in my
original post have issues.
On Thu, Aug 27, 2009 at 11:22 AM, Jason (Google) wrote:
JDO supports syntax like article.status but App Engine's datastore doesn't
support joins so you'll have to make article an embedded object in order to
use the query as you have it below:
http://code.google.com/appengine/docs/java/datastore/dataclasses.html#Embedded_Classes
Also, how have you defin
Any ideas, anyone?
On Sun, Aug 23, 2009 at 11:18 PM, Sam Walker wrote:
> Also, I get this error: *Can only filter by properties of a sub-object if
> the sub-object is embedded.* when I tried to access article while setting
> a fitler: query.setFilter("reviewer == reviewerParam && article.status
Also, I get this error: *Can only filter by properties of a sub-object if
the sub-object is embedded.* when I tried to access article while setting a
fitler: query.setFilter("reviewer == reviewerParam && article.status =
articleStatusParam");
What am I missing?
On Sat, Aug 22, 2009 at 6:02 PM, S
In the second model, how will I find all Articles being reviewed by A and B?
The only way I can think of is adding another derived field in Article:
Article {
HashSet reviews;
HashSet reviewers; // keys of Reviewers to help the query "find
all articles reviewed by A and B"
HashSet tags;
i
Oh sweet, I didn't know that.
That's awesome! Thanks for the quick reply.
On Sat, Aug 22, 2009 at 1:51 PM, datanucleus wrote:
>
> > I dont think I can do sth like (I can't access article.tags,
> article.status
> > as far as I know, correct?):
>
> Of course you can. JDO spec defines JDOQL, using
> I dont think I can do sth like (I can't access article.tags, article.status
> as far as I know, correct?):
Of course you can. JDO spec defines JDOQL, using Java syntax.
> query.setFilter("reviewer == reviewerParam && status == statusParam &&
> article.tags == tagParam && article.status = artic
16 matches
Mail list logo
