I am not a Google guy, but I think I can answer your question. key.parent
does exactly what it says it does, gives the key of the parent of the key
you have. So it is useful when you need that. An example might be if you
have the key to a comment on an article (and you have set it up such that
comments have the article as a parent) and you want to show all other
articles by the author of the article on which the comment was made.
Here is the bottom line when it comes to keys and queries in the context of
your post. If you do not have the key(s) you are performing a query. How
you get or know the keys is a different question. You may be able to
construct the keys by knowing something about the context. You may have
stored the keys someplace and have a pointer to them. You may have a key
and need its parent ... etc.
The db api and ndb api are the same in this regard. Specifically, the db
api does not have some special way to get entities from the datastore
without having the keys and also avoiding a query. You may not have
realized that you were performing a query before in some circumstance, but
you probably were.
If it just a syntax thing you are after, you can always add some sort of
getter method to your Article class to find all articles by a certain
author - but it will use a query.
On Monday, July 21, 2014 11:31:39 PM UTC-5, saintthor wrote:
>
> and, if you were a google guy, i'd like to ask what do you think the usage
> of key.parent is? in what instance it may be useful?
>
> 在 2014年7月22日星期二UTC+8上午3时55分28秒，Jay写道：
>>
>> Responding to your first post ... that is right. The parent key is part
>> of the entity's key. When you use get_by_id, this is just shorthand for
>> Key('Foo', 99).get().
>> You cannot get an entity by key unless you know the key, the whole key.
>>
>> You say you don't want to query, but your use case ... "give me all
>> articles for user A" ... sounds like a query.
>> articles = Article.query(Article.author == user_key)...
>>
>> If you want to do something like "most recent n articles" then you can
>> store those keys in a 'secondary index' of sorts and use ndb.get_multi()
>>
>> On Monday, July 21, 2014 8:11:20 AM UTC-5, saintthor wrote:
>>>
>>> to query may cost too many ops. i don't query.
>>>
>>>
>>>
>>> 在 2014年7月21日星期一UTC+8下午8时53分29秒，Kaan Soral写道：
>>>>
>>>> Not associated with google, also not an expert on ndb
>>>>
>>>> As far as I know key groups are related with consistency, in my
>>>> opinion, you shouldn't put article's and author's in the same group, there
>>>> is a 1/s write speed limit on entity groups, if you put them in the same
>>>> entity group, you could hit this limit more easily
>>>>
>>>> You don't even have to use referenceproperty's - I would just put the
>>>> author key in an article StringProperty named "author" and query for it,
>>>> if
>>>> I were you
>>>>
>>>
--
You received this message because you are subscribed to the Google Groups
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/d/optout.
