Details
-
Type:
Story
-
Status: To Do
-
Resolution: Unresolved
-
Fix Version/s: None
-
Component/s: Qserv
-
Labels:None
-
Story Points:8
-
Epic Link:
-
Team:Data Access and Database
-
Urgent?:No
Description
(created in response to DM-211)
This ticket should address the following inelegancies in the qserv-czar.
- QuerySession->QueryPipeline. The "session" abstraction has moved to a better place. The iterator portion should be shifted into its own separate class, though perhaps still associated with QueryPipeline. The iterator portion's new home should be amenable to eventually moving the actual query materialization to the worker, though we shouldn't introduce new abstractions until we are actually ready to move the substitution/materialization to the worker.
- QueryContext needs to be split into incoming external QueryContext and a sort of QueryClipboard for passing information between analysis/manipulation plugins. Eventually, I imagine a chain/tree of them attached to the select statements themselves in order to represent subquery scope nesting (which is complicated to represent and to reason about--nesting and the resulting namespace resolution is tricky), but I don't think we should try doing the chaining in the first phase. For this ticket, create QueryClipboard to hold the portion for interchange between analysis plugins. Query analysis plugins would then pass this object (which points at an immutable? QueryContext) between themselves. QueryClipboard probably should live in qana, QueryContext in query (unless there is a good reason to move it).
Attachments
Issue Links
Activity
| Description |
(created in response to This ticket should address the following inelegancies in the qserv-czar. * QuerySession->QueryPipeline. The "session" abstraction has moved to a better place. The iterator portion should be shifted into its own separate class, though perhaps still associated with * QueryPipeline. The iterator portion's new home should be amenable to eventually moving the actual query materialization to the worker, though we shouldn't introduce new abstractions until we are actually ready to move the substitution/materialization to the worker. * QueryContext needs to be split into incoming external QueryContext and a sort of QueryClipboard for passing information between analysis/manipulation plugins. Eventually, I imagine a chain/tree of them attached to the select statements themselves in order to represent subquery scope nesting (which is complicated to represent and to reason about--nesting and the resulting namespace resolution is tricky), but I don't think we should try doing the chaining in the first phase. For this ticket, create QueryClipboard to hold the portion for interchange between analysis plugins. Query analysis plugins would then pass this object (which points at an immutable? QueryContext) between themselves. QueryClipboard probably should live in qana, QueryContext in query (unless there is a good reason to move it). |
(created in response to This ticket should address the following inelegancies in the qserv-czar. * QuerySession->QueryPipeline. The "session" abstraction has moved to a better place. The iterator portion should be shifted into its own separate class, though perhaps still associated with * QueryPipeline. The iterator portion's new home should be amenable to eventually moving the actual query materialization to the worker, though we shouldn't introduce new abstractions until we are actually ready to move the substitution/materialization to the worker. * QueryContext needs to be split into incoming external QueryContext and a sort of QueryClipboard for passing information between analysis/manipulation plugins. Eventually, I imagine a chain/tree of them attached to the select statements themselves in order to represent subquery scope nesting (which is complicated to represent and to reason about--nesting and the resulting namespace resolution is tricky), but I don't think we should try doing the chaining in the first phase. For this ticket, create QueryClipboard to hold the portion for interchange between analysis plugins. Query analysis plugins would then pass this object (which points at an immutable? QueryContext) between themselves. QueryClipboard probably should live in qana, QueryContext in query (unless there is a good reason to move it). |
| Description |
(created in response to This ticket should address the following inelegancies in the qserv-czar. * QuerySession->QueryPipeline. The "session" abstraction has moved to a better place. The iterator portion should be shifted into its own separate class, though perhaps still associated with * QueryPipeline. The iterator portion's new home should be amenable to eventually moving the actual query materialization to the worker, though we shouldn't introduce new abstractions until we are actually ready to move the substitution/materialization to the worker. * QueryContext needs to be split into incoming external QueryContext and a sort of QueryClipboard for passing information between analysis/manipulation plugins. Eventually, I imagine a chain/tree of them attached to the select statements themselves in order to represent subquery scope nesting (which is complicated to represent and to reason about--nesting and the resulting namespace resolution is tricky), but I don't think we should try doing the chaining in the first phase. For this ticket, create QueryClipboard to hold the portion for interchange between analysis plugins. Query analysis plugins would then pass this object (which points at an immutable? QueryContext) between themselves. QueryClipboard probably should live in qana, QueryContext in query (unless there is a good reason to move it). |
(created in response to This ticket should address the following inelegancies in the qserv-czar. * QuerySession->QueryPipeline. The "session" abstraction has moved to a better place. The iterator portion should be shifted into its own separate class, though perhaps still associated with * QueryPipeline. The iterator portion's new home should be amenable to eventually moving the actual query materialization to the worker, though we shouldn't introduce new abstractions until we are actually ready to move the substitution/materialization to the worker. * QueryContext needs to be split into incoming external QueryContext and a sort of QueryClipboard for passing information between analysis/manipulation plugins. Eventually, I imagine a chain/tree of them attached to the select statements themselves in order to represent subquery scope nesting (which is complicated to represent and to reason about--nesting and the resulting namespace resolution is tricky), but I don't think we should try doing the chaining in the first phase. For this ticket, create QueryClipboard to hold the portion for interchange between analysis plugins. Query analysis plugins would then pass this object (which points at an immutable? QueryContext) between themselves. QueryClipboard probably should live in qana, QueryContext in query (unless there is a good reason to move it). |
| Description |
(created in response to This ticket should address the following inelegancies in the qserv-czar. * QuerySession->QueryPipeline. The "session" abstraction has moved to a better place. The iterator portion should be shifted into its own separate class, though perhaps still associated with * QueryPipeline. The iterator portion's new home should be amenable to eventually moving the actual query materialization to the worker, though we shouldn't introduce new abstractions until we are actually ready to move the substitution/materialization to the worker. * QueryContext needs to be split into incoming external QueryContext and a sort of QueryClipboard for passing information between analysis/manipulation plugins. Eventually, I imagine a chain/tree of them attached to the select statements themselves in order to represent subquery scope nesting (which is complicated to represent and to reason about--nesting and the resulting namespace resolution is tricky), but I don't think we should try doing the chaining in the first phase. For this ticket, create QueryClipboard to hold the portion for interchange between analysis plugins. Query analysis plugins would then pass this object (which points at an immutable? QueryContext) between themselves. QueryClipboard probably should live in qana, QueryContext in query (unless there is a good reason to move it). |
(created in response to This ticket should address the following inelegancies in the qserv-czar. * QuerySession->QueryPipeline. The "session" abstraction has moved to a better place. The iterator portion should be shifted into its own separate class, though perhaps still associated with * QueryPipeline. The iterator portion's new home should be amenable to eventually moving the actual query materialization to the worker, though we shouldn't introduce new abstractions until we are actually ready to move the substitution/materialization to the worker. * QueryContext needs to be split into incoming external QueryContext and a sort of QueryClipboard for passing information between analysis/manipulation plugins. Eventually, I imagine a chain/tree of them attached to the select statements themselves in order to represent subquery scope nesting (which is complicated to represent and to reason about--nesting and the resulting namespace resolution is tricky), but I don't think we should try doing the chaining in the first phase. For this ticket, create QueryClipboard to hold the portion for interchange between analysis plugins. Query analysis plugins would then pass this object (which points at an immutable? QueryContext) between themselves. QueryClipboard probably should live in qana, QueryContext in query (unless there is a good reason to move it). |
| Description |
(created in response to This ticket should address the following inelegancies in the qserv-czar. * QuerySession->QueryPipeline. The "session" abstraction has moved to a better place. The iterator portion should be shifted into its own separate class, though perhaps still associated with * QueryPipeline. The iterator portion's new home should be amenable to eventually moving the actual query materialization to the worker, though we shouldn't introduce new abstractions until we are actually ready to move the substitution/materialization to the worker. * QueryContext needs to be split into incoming external QueryContext and a sort of QueryClipboard for passing information between analysis/manipulation plugins. Eventually, I imagine a chain/tree of them attached to the select statements themselves in order to represent subquery scope nesting (which is complicated to represent and to reason about--nesting and the resulting namespace resolution is tricky), but I don't think we should try doing the chaining in the first phase. For this ticket, create QueryClipboard to hold the portion for interchange between analysis plugins. Query analysis plugins would then pass this object (which points at an immutable? QueryContext) between themselves. QueryClipboard probably should live in qana, QueryContext in query (unless there is a good reason to move it). |
(created in response to This ticket should address the following inelegancies in the qserv-czar. * QuerySession->QueryPipeline. The "session" abstraction has moved to a better place. The iterator portion should be shifted into its own separate class, though perhaps still associated with QueryPipeline. The iterator portion's new home should be amenable to eventually moving the actual query materialization to the worker, though we shouldn't introduce new abstractions until we are actually ready to move the substitution/materialization to the worker. * QueryContext needs to be split into incoming external QueryContext and a sort of QueryClipboard for passing information between analysis/manipulation plugins. Eventually, I imagine a chain/tree of them attached to the select statements themselves in order to represent subquery scope nesting (which is complicated to represent and to reason about--nesting and the resulting namespace resolution is tricky), but I don't think we should try doing the chaining in the first phase. For this ticket, create QueryClipboard to hold the portion for interchange between analysis plugins. Query analysis plugins would then pass this object (which points at an immutable? QueryContext) between themselves. QueryClipboard probably should live in qana, QueryContext in query (unless there is a good reason to move it). |
| Rank | Ranked higher |
| Rank | Ranked lower |
| Rank | Ranked higher |
| Reporter | Daniel Wang [X] [ danielw ] | Fritz Mueller [ fritzm ] |
| Remote Link | This issue links to "Page (Confluence)" [ 26775 ] |
| Watchers | Daniel Wang [X] [ Daniel Wang [X] ] | Fritz Mueller [ Fritz Mueller ] |
| Epic Link | DM-2881 [ 17862 ] |
| Urgent? | off |