>From my understanding you will need to use the second version of the
query for strongly consistent look ups (or you can query by building
the key, but this is only useful when you need to get a specific
entity). Building a query such as the first one will NOT result in
strong consistency using HR.
As for the custom index question, I've no experience on this but from
what I can gather you can try:
db.Query().ancestor(org_key).filter('position', manager).fetch(1000)
The caveat with this kind of query is that if <org_key> is the parent
or the parent of the parent of any entity, they will be returned using
this query (assuming the entities have a "position" attribute equal to
<manager>). If your data structure won't fall into this caveat, you
can safely perform this query without the use of additional custom
indexes. Additionally, you can prefix all attributes in a specific
model with a unique identifier for that Model (such as its name:
employee_position).
However, from what I read on the SDK docs, I wouldn't expect the
second query to require a custom index, but again, I cannot speak from
experience.
I hope this helps!
On Nov 17, 12:35 pm, johnP <[email protected]> wrote:
> Second try... Wondering if anyone has an answer to these questions.
> Thanks!
>
> On Nov 14, 8:14 am, johnP <[email protected]> wrote:
>
>
>
>
>
>
>
> > My data currently on MS is organized into entities.
> > - For example, let's say that each Organization is it's own entity
> > group.
>
> > Most of my queries are within an entity/organization. An example of a
> > typical query is:
> > - Employee.all().filter('organization =', org).filter('position =',
> > manager).fetch(1000)
>
> > This same query can also be done using an ancestor query:
> > - Employee.all().ancestor(org_key).filter('position =',
> > manager).fetch(1000)
>
> > The first version of the query does not require a custom index, but
> > the second version does.
>
> > My questions:
> > 1. Will moving from the first version to the the second version of
> > the query require adding custom indexes? Or am I missing something?
> > 2. Clarification on Strong Consistency in HR: Is it necessary to use
> > the ancestor() operator, or is simply querying within an entity group
> > strongly consistent? My assumption has been that for queries that
> > must be strongly consistent, it will be necessary to migrate from the
> > first format to the second format (increasing the number of custom
> > indexes I need to carry). Is this assumption correct?
--
You received this message because you are subscribed to the Google Groups
"Google App Engine" 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?hl=en.
