sorry! correction of: "filter column is named 'f', value is named 'v'"
the 'f' and 'v' are actually a the same property now, so:
select from RelationIndex where f == 'roleA' && f == 'registered' && f
== '{User}' && f == '(lastName') && f > 'a.Smith:xJ8mFc9r' order by f
asc;
like that.
On Aug 19, 3:49 am, Juraj Vitko <[email protected]> wrote:
> 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 [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
-~----------~----~----~----~------~----~------~--~---
