It is indeed a more complex query, and the IN values are keys. At one
point, I had tried to make them key values in a named reference
collection, but while the data store never complained, it never
returned any results.
Can you confirm that it is impossible to make an entity query that
filters by normal prop vals and by a list of keys in a collection?
e.g. Entity.gql('WHERE prop1 = :val1 AND named_collection
IN :key_list', val1=val, key_list=keys)
Separately, spurred on by your comments, I cleared the datastore and
started again. Now, the index explosion is not occurring. I guess
that some interim query experiment requested such indexes, and
stopping the datastore and deleting the indexes out of the index.yaml
file was not sufficient to clear them, so they kept reappearing in
index.yaml.
On Mar 3, 11:29 pm, ryan <[email protected]> wrote:
> On Mar 1, 2:13 pm, Andy Freeman <[email protected]> wrote:
>
> > > However, when I do this, the dev_server creates a bunch of index
> > > definitions, so that I have one with 1 property if there's 1 value in
> > > the IN set, 15 index properties if there are 15 values in the IN set,
> > > and so on.
>
> > Are all of these index properties necessary in production? Will a
> > production query with an IN set with 4 members fail if the test set
> > used to generate index.yaml has IN sets with 1, 3, and 5 members?
>
> i have to admit, i don't entirely understand the problem. indices are
> only needed with different combinations of property names, not filter
> values. IN queries fan out to multiple queries on the exact same
> combination of property names; only the filter values change. changing
> the number of filter values shouldn't change the indices needed by the
> subqueries. for example, SELECT * FROM Foo WHERE x in [0, 1] fans out
> to:
>
> SELECT * FROM Foo WHERE x = 0
> SELECT * FROM Foo WHERE x = 1
>
> while SELECT * FROM Foo WHERE x in [0, 1, 2, 3] fans out to
>
> SELECT * FROM Foo WHERE x = 0
> SELECT * FROM Foo WHERE x = 1
> SELECT * FROM Foo WHERE x = 2
> SELECT * FROM Foo WHERE x = 3
>
> all of the subqueries use the same index. here, it's a built-in single
> property index, but it could be a composite index if there was an
> additional filter or sort order.
>
> given that, i suspect there's more going on here, or at least a
> substantially more complicated query. Devel63, any chance you could
> post your exact query and filter values, ie the values for the IN set?
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
