So guys thanks for the good IRC chat:) Basically even if this was implemented, it would be too costly on resources.
What I needed, was to change my thinking to better fit App Engine. The good thing is, that if one optimizes for App Engine, then his app will run faster _everywhere_. Basically, the best method for being able to show filtered data in a Grid that can be sorted _and_ paged on any column, one needs to pre- filter the data (upon created/update/delete) into separate kinds. This filtered kind then can be sorted on using the default indexes, because filter was already applied. Also, the data stored in this filtered kind is not the exact copy of the original data, but rather its string representation with unique suffixes to support lexicographical ordering and no-equality-restart pagination. The advantage of this is also that a much more sophisticated filtering can be used, not just the built-in query operators. One has to add logic to support recomputation of the filtered kind if the filter code or sorting-enabled columns change as the app is evolving, but that's a one time job and can be reused if done properly. On Aug 19, 6:01 am, Juraj Vitko <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
