[TransWarp] Topics for tomorrow, and beyond

[Phillip J. Eby]

These are just notes to myself on things yet to be written in the querying 
saga...


Packaging

   Should we have a peak.query?  this is likely to be multiple modules:

      filter operators
      relational operators
      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

     Syntax
       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


Join operators

   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


Filter operators

   Aggregates - no syntax yet

   IN()
     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)

   NOT()
     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,
       correlations, etc.)


SQL Generation
   ...and cross-database joins