[TransWarp] Topics for tomorrow, and beyond
Phillip J. Eby
pje at telecommunity.com
Wed Oct 15 23:53:29 EDT 2003
These are just notes to myself on things yet to be written in the querying
Should we have a peak.query? this is likely to be multiple modules:
lots of interfaces
query execution for Plain Ol' Python Objects
maybe C speedups for the preceding, at some point
"User-friendly" Query Syntax
Foo.where() doesn't look right any more
No aggregate syntax yet
How to specify functions?
Maybe we need an actual query "language"?
Benefit: *much* easier syntax for everything
functions, logical ops, and comparisons are trivial to write
easier to declare parameters and variables
other shortcuts possible
Minus: More time to implement!
Minus: queries have no meaning without an environment
(to define base sets, functions)
Minus: literals & type conversions annoying to implement
Not OQL, it's as hard to use as SQL
(But it's a standard...)
ConQuer-like conceptual approach would be nice
...but too English-like for our needs
Theta join (standard)
Outer join, Existence join (what's the associativity of these?)
Aggregates - how to specify, fold?
Constant folding to remove outer joined tables by relocating
criteria to base table
Aggregates - no syntax yet
map to set of OR()'s for constant sequence
EXISTS join for correlation parameter or subexpression
what do we do if parameter is input? SQL generation will suck
subexpression for IN() would need a way to create a table alias
(probably better just to use correlation)
what happens to traversals underneath?
force not_exists join?
that would mean no output parameters allowed
What happens to an OR() that contains traversals?
Should an outer-join be forced? How?
How does this affect folding of outer joins?
Haven't specified auto-EXISTS semantics fully under latest paradigm
Need a traverser interface
Architecture for filter execution with actual result generation
(i.e. filters should be applicable to regular objects w/out
a relational conversion, and still output any aggregates,
...and cross-database joins
More information about the PEAK