On a query with equality filter on a list property, would it be
possible to:
1) _not_ discard the sort order on that property,
2) allow for inequality test on smallest/highest value of that list
property (similar to ordering)
That way it would be possible to implement "relation indexes" using a
table with a single list property (no custom indexes required!)
The property would look something like: [ a.val:unique, filter1,
filter2, filterN, z.val:unique ]
The two 'val' is the same value to be lexicographically ordered (so
numeric types must be converted to appropriate strings).
The a. and z. prefixes would be actually the lowest and highest
printable ascii chars, just so that they are always the lowest and
highest value of the list property, and can be used in asc and desc
ordering.
The filters would be used for equality filtering.
Then this query would be possible:
select from kind where prop == filter1 && prop == filter2 && prop >
'a.someval:unique' order by prop asc
(the optional greater-than operator is there to support paging)
The sort order would _not_ be dropped only if specifically requested
by the user, as to not incur needless overhead on current queries.
A real-use example of a relation index table shared by multiple kinds:
select from RelationIndex where f == 'roleA' && f == 'registered' && f
== '{User}' && f == '(lastName') && v > 'Smith:xJ8mFc9r' order by v
asc;
- filter column is named 'f', value is named 'v'
- the { and } are used to distinguish a kind name filter
- the ( and ) are used to distinguish a column name filter
- the 'v' always contains value belonging to that table/column
- 'xJ8mFc9r' is the unique suffix
The benefits of the "relation indexes" technique using a single list
property:
1) single-query forward/backward bookmark paging (no equality restarts
needed),
2) asc/desc ordering on any number of columns (one column at a time)
3) no custom indexes required (hard-limited to 100 per app)
One could argue that it is simpler to implement relation indexes using
a table with 2 columns: "filters" and "value" - however:
1. this table needs a custom index
2. due to the custom index, max. 4 filters can be queried on at the
same time (tested)
3. this custom index must enumerate all the filters (filter asc,
filter asc, filter asc, filter asc, value asc + the same for value
desc) - otherwise custom index space is wasted with permutations
4. due to point 3., each row in the index table must contain a 'dummy'
filter value that is used to "park" the unused filters, only so that
the query always matches the custom index definition, ie. "where
filter == 'abc' && filter == 'def' && filter == 'dummy' && filter ==
'dummy'"
5. both runtime and storage overhead of this approach are much higher
than the single-property approach (due to the list property being
multiplied by 2 for indexing)
Your opinions?
J.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
To unsubscribe from this group, send email to
google-appengine+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/google-appengine?hl=en
-~----------~----~----~----~------~----~------~--~---
