Cube query flow redesign

[Stiivi]

Problem

Current query flow and generation is not very transparent and there is no clear separation of concerns – which part is doing what.

• AggregationBrowser – subclassable by the backends. Has main entry point aggregate() with lots of arguments that need to be converted using prepare_*() functions.
• The whole flow is hidden under one huge step that happens inside in the browser – from query composition through compilation, execution and post-aggregation.
• Store has not well defined interface, it is just dangling there for the browser

Details

• separate user-oriented query creation in string references (names of metadata objects) from object graph references (metadata objects, such as Dimension, Level ,...). See
• expose intermediate step – prepared query – that can be passed to the execution engine (Store) repeatedly
• expose interface for compiled query that might be executed by external tools within the same store as the query was generated for
• wrap the query in a single object that can be converted to/from other representation such as JSON dictionary as a whole
• be ready for future Drill-across #245
• make writing unit tests easier

Proposed design:

Impact on Existing Code

New recommended flow of query creation will be created. Breaking changes: any construction of cells with model objects will fail For backward compatibility the Browser will wrap functionality of the new components.

Should NOT break server API v2.

References

Depends on:

• 407 Remove cube from Cell

• 395 Change sort attribute to enum (required)

Has impact on:

• 403 Incomplete and broken unittests – will be easier to write the tests

Dependents:

• 245 Drill Across

[Stiivi]

Copy from #407: places where Cell is using Dimension object or places affected by it:

• sql/query.py uses cut dimension as str(cut.dimension) (good)
• query/browser.py is using str() or cube lookup, which is the same (good)
• query/cells.py
  • has property Cell.all_attributes which does not seem to be used anywhere
  • has Cell.slice and Cell.point_slice which are not used anywhere except documentation and they should be moved into the new Query.
  • Cell.drilldown which seems not to be used and should be moved to the new Query
  • Cell.cut_for_dimension which is unused and should be removed
  • Cell.point_cut_for_dimension which should be moved (see below)
  • Cell.rollup_dim which is unused and is a candidate for removal/move to the new Query
  • Cell.rollup - remove, move to the Query
  • Cell.level_depths – unused, to be removed
  • Cell.deepest_levels - unused, was used for Periods-to-date, might be moved to Query?
  • Cell.contains_level – unused, to be removed - removed by #407
  • Cell.point_slice - unused, to be removed or moved to query
  • Cell.is_base - unused, to be removed - removed by #407
• query/browser.py uses Cell.point_cut_for_dimension
  • used in AggregationResult.table_rows
  • used in levels_from_drilldown() which sohuld receive cube as well as Drilldown should receive a cube.