Product spec for Views #22
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1 +1,30 @@ | ||
| *.pyc | ||
|
|
||
| # Don't commit Obsidian files, allows wiki to be edited in Obsidian. | ||
| .obsidian | ||
|
|
||
| ## MAC ## | ||
|
|
||
| # General | ||
| .DS_Store | ||
| .AppleDouble | ||
| .LSOverride | ||
|
|
||
| # Thumbnails | ||
| ._* | ||
|
|
||
| # Files that might appear in the root of a volume | ||
| .DocumentRevisions-V100 | ||
| .fseventsd | ||
| .Spotlight-V100 | ||
| .TemporaryItems | ||
| .Trashes | ||
| .VolumeIcon.icns | ||
| .com.apple.timemachine.donotpresent | ||
|
|
||
| # Directories potentially created on remote AFP share | ||
| .AppleDB | ||
| .AppleDesktop | ||
| Network Trash Folder | ||
| Temporary Items | ||
| .apdisk |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,11 @@ | ||
| --- | ||
| title: Product Specs | ||
| description: List of product specs | ||
| published: true | ||
| date: 2022-01-13T19:49:54Z | ||
| tags: | ||
| editor: markdown | ||
| dateCreated: 2022-01-13T19:49:54Z | ||
| --- | ||
|
|
||
| - [Views](/product/specs/2022-01-views) |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,30 @@ | ||
| --- | ||
| title: Views in Mathesar | ||
| description: Spec for Views in Mathesar | ||
| published: true | ||
| date: 2022-01-13T19:49:54Z | ||
| tags: | ||
| editor: markdown | ||
| dateCreated: 2022-01-13T19:49:54Z | ||
| --- | ||
|
|
||
| **Date**: 2022-01 | ||
| **Author**: Kriti Godey | ||
|
|
||
| # Introduction | ||
|
|
||
| Fundamentally, **Views** are saved database queries. This means that in order to work with Views in Mathesar, we need to translate every concept that can be used in [PostgreSQL queries](https://www.postgresql.org/docs/14/queries.html) to our end users in a user-friendly way. | ||
|
|
||
| Since this spec will be long, I've decided to split it up into multiple pages. | ||
|
|
||
| - [Assumptions](/product/specs/2022-01-views/01-assumptions.md) | ||
| - [Modeling Views](/product/specs/2022-01-views/02-modeling-views.md) | ||
| - [Modeling View Columns](/product/specs/2022-01-views/03-modeling-view-columns.md) | ||
| - [UI Requirements for Views](/product/specs/2022-01-views/04-ui-requirements-for-views.md) | ||
| - [Mapping DB Queries to Views](/product/specs/2022-01-views/05-mapping-db-queries-to-views.md) | ||
|
|
||
| There are still some details to be figured out, including: | ||
| - which database functions we'll support for the alpha release and how that will work. | ||
| - how we'll handle different table `JOIN` types. | ||
|
|
||
| This spec will be updated with more details on those and other questions raised once the initial concepts listed here have been ironed out. | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,17 @@ | ||
| --- | ||
| title: Views: Assumptions | ||
| description: | ||
| published: true | ||
| date: 2022-01-13T19:49:54Z | ||
| tags: | ||
| editor: markdown | ||
| dateCreated: 2022-01-13T19:49:54Z | ||
| --- | ||
|
|
||
| ## Assumptions | ||
| I'm making the following assumptions in the rest of the spec about how we want to work with Views in Mathesar. | ||
|
|
||
| - We **do not** need to support creating or editing Views based on every conceivable database query in Mathesar. We will be focusing on allowing common use cases. | ||
| - We **do** need to support viewing Views based on any conceivable database query correctly, even if they can't be edited. Users should be able to connect a database with existing Views to Mathesar and have those Views show up correctly. | ||
|
There was a problem hiding this comment. Does this imply being able to view the definition of the view somehow, or just the actual tabular output? I.e., if they combine something we don't support with something we do (e.g., a filter we understand), do we need to try to pick out the filter and show that in the UI? There was a problem hiding this comment. Yes, that's the idea. If there's a filter we don't understand, I think we would show it as an unknown filter in the UI and not allow them to edit that part. |
||
| - At the moment, we **only** care about the final output of the views. If a view uses a subquery, CTE, union, intersection, etc. internally, we will not be representing those to the user in the UI (unless they look at the underlying SQL query). | ||
|
There was a problem hiding this comment. To double-check: I thought if a user creates a view, the creation would be visible (insofar as it was created in Mathesar). I.e., if they filter and group a table to create the view, they'd be able to see what those elements were in the UI. Is this incorrect? There was a problem hiding this comment. That is correct. But if a view was created outside of Mathesar and involved a CTE creating some derived columns that don't reflect in the final tabular output of the view, the user will not see anything about those derived columns. |
||
| - We eventually want to allow users to create Views using SQL queries through the web interface, but this will not be prioritized for the alpha release. | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,84 @@ | ||
| --- | ||
| title: Views: Modeling Views | ||
| description: | ||
| published: true | ||
| date: 2022-01-13T19:49:54Z | ||
| tags: | ||
| editor: markdown | ||
| dateCreated: 2022-01-13T19:49:54Z | ||
| --- | ||
|
|
||
| Here's how I think we should model views in our API and UI. Each heading represents an attribute of Views. | ||
|
There was a problem hiding this comment. On most/all of the sections in this page, we have the possibility for confusion between the transformations that create a view, and then further transformations applied to that view. For example, I can create a view by filtering based on some row. Then, looking at that view, I can filter to further reduce the dataset without saving the result as a view. I think this multiple-level transformation isn't very clear from the way these sections are laid out. This is probably going to be challenging to portray in a sensible manner. Note that I'm thinking in the abstract here, not necessarily in our current UI (I don't recall if we have that functionality or not). I do think that being able to manipulate / sort / group / filter the data in a persisted view would be useful for most users, though, and that comes with the problem I mentioned. There was a problem hiding this comment. Please see comment about "saved" and "unsaved" filters above. |
||
|
|
||
| Before I get into attributes, here's an example table named `Movies` that I'll use to illustrate different types of Views. | ||
|
|
||
| | ID | Title | Year | Genre | | ||
| |-|-|-|-| | ||
| | 1 | The River Wild | 1994 | Thriller | | ||
| | 2 | Don't Look Up | 2021 | Comedy | | ||
| | 3 | Daylight | 1996 | Action | | ||
| | 4 | Jason Bourne | 2016 | Action | | ||
|
|
||
| ## Query | ||
| This is the SQL query that defines the view. This is **required**. | ||
|
|
||
| ## Columns | ||
| Output columns of the View's Query, they will be shown in the UI. At least one column is **required** for a view. | ||
|
|
||
| Column attributes are defined [in a separate page](/product/specs/2022-01-views/03-modeling-view-columns.md). | ||
|
|
||
| ## Rows | ||
| These are the output rows of the View's Query. Rows are **not required**, Views can contain 0 rows. | ||
|
|
||
| ## Filters | ||
| Views can have filters applied. Unlike Tables, view filters are not necessarily related to the columns that are present in the view. | ||
|
|
||
| Using the example table above, imagine a view created from the query `SELECT ID, Title FROM Movies WHERE Year > 2000;` This will return this view: which is filtered by Year even though it's not a column in the View. | ||
|
There was a problem hiding this comment. Do we intend to show this filter in the 'filters dropdown' on the frontend? I think it's best if we consider this just as part of the query for the view, and not as a filter that can be manipulated. Reasoning:
There was a problem hiding this comment.
Please don't assume any particular design for Views as yet. This spec is aimed at clarifying product requirements which will then influence the requirements for design. There was a problem hiding this comment. e.g. see this UX for adding a filter in Chart.io https://chartio.com/docs/visual-sql/start-a-query/visual-mode/#add-a-filter. Even if we don't allow the user to manipulate the filters, it seems like it would be useful to show the filter applied (without them having to look at the query or understand SQL), otherwise non-technical users may get confused about why the View is not showing all the data they expect. And if we're figuring out how to represent the filter, that's most of the work, so why not let them change it? There was a problem hiding this comment. Okay, that makes sense. I've been explaining to people lately that tables are a structured representation of raw data and views are reports generated from those tables. When I look at views as reports, it kind of makes them seem immutable, which is true from a db standpoint. But considering that we intend to represent views as mutable entities on the frontend, allowing users to edit the base filter makes sense. I'm only concerned on how well we would be able to represent the differences between tables and views to the user. There was a problem hiding this comment. Argh, I couldn't see this conversation while doing my own review, so there's some overlap. To reiterate what I said in other spots, I think we're missing clarity between the filter that defines a view, and a filter applied to a view. I think we need both, and since from SQLAlchemy a view is a table (more-or-less), filtering a previously created view is the same as filtering a table. I think we should be crystal clear on this point, lest we create confusion for users. This applies to all transformations that can be used to define a view. There was a problem hiding this comment.
Views are more than just saved filters. They can be referenced by other queries/views, can have their own set of filters/sorts, more of hierarchical structures which are closer to a table in characteristics. If we call them unsaved filters, it would be misleading as In the case of very deep Views(table1-> view1->view2), they need to show that hierarchy and users should be able to determine where certain operations like filter/sort took place. There was a problem hiding this comment.
Hierarchy and composition are the reason why I would not call them saved filters. There was a problem hiding this comment. @silentninja said
This is a succinct way to put it; I agree. There was a problem hiding this comment.
Views should be treated as similar to a table. so a view name could help with understanding what the data the view holds instead of having to look where or how it was generated. This is more of a convention rather an accurate description. If named properly, we don't have to worry about showing how the view was generated unless required, where we could do complex diagrams like dependency graphs. Generally, when working with a There was a problem hiding this comment.
Dependency graph: As for cluttered filters, I don't have visualisation other than our existing filter dropdown, but the reason why I think it would be cluttered is that we could end up with too many filters as a list(maybe along with the entity name they came from) in case of a deep view |
||
|
|
||
| | ID | Title | | ||
| |-|-| | ||
| | 2 | Don't Look Up | | ||
| | 4 | Jason Bourne | | ||
|
|
||
| ## Sorting | ||
| Views can have sorting applied. Unlike Tables, view sorting is not necessarily related to the columns that are present in the view. | ||
|
|
||
| Using the example table above, imagine a view created from the query `SELECT ID, Title FROM Movies ORDER BY Year;` This will return this view, which is ordered by Year even though it's not a column in the View. | ||
pavish marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| | ID | Title | | ||
| |-|-| | ||
| | 1 | The River Wild | | ||
| | 3 | Daylight | | ||
| | 4 | Jason Bourne | | ||
| | 2 | Don't Look Up | | ||
|
|
||
| ## Aggregations | ||
| These are functions applied to the view as a whole (rather than to individual columns). | ||
|
|
||
| Using the example table above, imagine a view created from the query `SELECT Genre FROM Movies GROUP BY GENRE;` | ||
|
|
||
| | Genre | | ||
| |-| | ||
| | Thriller | | ||
| | Comedy | | ||
| | Action | | ||
|
|
||
| ## Row Limit | ||
| This is the number of rows the View is limited as per its Query. | ||
|
|
||
| Please note that this is different from pagination; it represents a limit in the database. | ||
|
|
||
| ## Row Offset | ||
| This is the number of the first row of the result of the Query that the View's rows start at. | ||
|
|
||
| Please note that this is different from pagination; it represents a limit in the database. | ||
|
|
||
| ## Groups | ||
| Groups are similar to table grouping, they sort and then visually group rows into sections. They are a Mathesar-specific frontend concept and do not reflect anything related to the database or the View's Query. | ||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,28 @@ | ||
| --- | ||
| title: Views: Modeling View Columns | ||
| description: | ||
| published: true | ||
| date: 2022-01-13T19:49:54Z | ||
| tags: | ||
| editor: markdown | ||
| dateCreated: 2022-01-13T19:49:54Z | ||
| --- | ||
|
|
||
| Here's how I think we should model view columns in our API and UI. Each heading represents an attribute of a View Column. | ||
|
|
||
| ### Data Type | ||
| - **Definition**: This is the final data type of the content of the column after any computations etc. are applied. | ||
|
There was a problem hiding this comment. We cannot always determine the exact data type of a view's column, as it could be a function that returns a polymorphic type. So we should be taking this into consideration and support having polymorphic column types There was a problem hiding this comment. You can create a function like that, and even use it to generate the column, but if PostgreSQL can't figure out a non-pseudo-type for the column, it'll throw an error. All polymorphic types are pseudo types. https://www.postgresql.org/docs/13/datatype-pseudo.html So, you can't have a column of type, e.g., |
||
| - **Allowed values**: same as Table data types. | ||
| - **Required**. Data type should always be set, at the very least, we can treat unknown data types as text. | ||
|
|
||
| ### Data Sources | ||
| - **Definition**: This is the set of source columns that are used to generate the data in the current View column. | ||
|
There was a problem hiding this comment. Will it be just referring to the parent of view ignoring the ancestors? There was a problem hiding this comment. Yes, it will reference the immediate parent. If the parent is another view, you'll have to go look at that view to find the source. There was a problem hiding this comment. I do like the idea of a dependency graph eventually but I don't think it's worth doing before the alpha release. |
||
| - **Allowed values**: references to other Table or View columns, including other columns in the same View. | ||
| - **Optional**: This could be empty for purely calculated columns (e.g. using the Postgres `random()` function and putting the output in a column) | ||
|
|
||
| ### Data Formula | ||
|
There was a problem hiding this comment. I'm not sure Data Sources and Data Formula should be separate. The formula must include the sources (if there are any) to make sense. There was a problem hiding this comment. The formula would include the sources, yes. I'm borrowing Element's UI to illustrate the idea, imagine Matrix channels are data sources. Formula would be something like: Sources would just be list of variables used in the formula: There was a problem hiding this comment. I like how you made that illustration, Kriti. Creative. I'm leaning towards dropping Data Sources, and querying the Data Formula for what columns it references. That way there would be a single source of truth for this. Having Data Sources at the same level of interface as Data Formula is a bit in conflict with the fact that one is derived from the other. There was a problem hiding this comment. We won't always have a Formula, e.g. a view that's built on the query We also may not have a Source for a column with a Formula - e.g. a column might be generated using the |
||
| - **Definition**: This is the formula used to generate data in for this column. | ||
| - **Allowed values**: SQL function + operators | ||
| - **Optional**: Columns that are direct copies of other columns from tables or views won't have a formula. | ||
pavish marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| We should allow users to either use a pre-set set of formulas or (in the future) enter a custom formula using whatever functions are installed on their Postgres database. | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,78 @@ | ||
| --- | ||
| title: Product Specs | ||
| description: Views: UI Requirements for Views | ||
| published: true | ||
| date: 2022-01-13T19:49:54Z | ||
| tags: | ||
| editor: markdown | ||
| dateCreated: 2022-01-13T19:49:54Z | ||
| --- | ||
|
|
||
| Based on the models defined for [views](/product/specs/2022-01-views/02-modeling-views.md) and their [columns](/product/specs/2022-01-views/03-modeling-view-columns.md), the first version of Views should support the following features. | ||
|
|
||
| I've marked the features we should support as "for alpha release", but I've also listed a few potential future features so that we can think about them while designing code architecture and UI/UX. | ||
|
|
||
| ## Query | ||
| - **For alpha release**: Users should be able to see the query associated with a View after it has been loaded. | ||
| - **Potential future features**: | ||
| - Users can edit the query associated with a View. | ||
| - Users can create a new View using a query. | ||
|
|
||
| ## Columns | ||
| - **For alpha release**: Users should be able to see all columns associated with a view. Each column should show: | ||
| - Data Type (non-editable) | ||
| - Data Sources (editable if there's no Formula) | ||
|
There was a problem hiding this comment. I don't understand the goal of making the data sources editable. Would the intention be to drop a different column in in place of the one shown? Wouldn't it be simpler / smoother to remove that column and add a different one? There was a problem hiding this comment. I think that if users want to reuse a view w a different table, this might come in handy. I think removing/adding a new column is probably easier w SQL than it is through the interface. There was a problem hiding this comment. Now I definitely don't understand. Do you want them to use sort of the same processing, but on a different data set? I.e., maybe apply the same sequence of filters and grouping? Do you have an example of what you're envisioning there (i.e., with actual table names and fake data)? There was a problem hiding this comment. I don't think we can reuse views with different tables, at least not in any easy way that's worth doing for the alpha release. I'll remove data sources being editable, it would be better to drop and create new columns. |
||
| - Data Formula (editable in simple cases) | ||
| - **Potential future features**: | ||
| - Show virtual columns involved in view creation (via CTEs, subqueries, etc.) | ||
| - Allow editing data formula using SQL | ||
|
|
||
| ## Rows | ||
| - **For alpha release**: | ||
| - Users should be able to see the rows associated with a view. | ||
| - If a cell is a direct representation of a record, users should be able to edit that record via that cell. | ||
| - If a column is a direct representation of a record, users should be able to add a new record via that cell. | ||
|
There was a problem hiding this comment. To double-check; the intent would be to pop up some "record input" UI when trying to edit the cell, correct? I.e,. since the entire table wouldn't be there, they'd need some interface to input the rest of the row in the associated table. What if the column is the join column? Would they edit the record in both tables, or just one? (Or does that not count as a direct representation?) There was a problem hiding this comment. Yes, that's the idea. I think if it's a join column, it should be updated in both tables. I'll specify. There was a problem hiding this comment. Actually, on second thought, join columns should not count as direct representations. Only columns with a single data source count. |
||
| - **Potential future features**: | ||
| - Users can edit the query associated with a View. | ||
| - Users can create a new View using a query. | ||
|
|
||
| ## Filters | ||
| - **For alpha release**: | ||
| - Users should be able to see what filters are applied to their View. | ||
| - Users should be able to edit and delete filters applied to their view, including basic use cases for columns that are not visible in the View. | ||
|
There was a problem hiding this comment. I don't quite understand this. Does this refer to editing the underlying query via the filter UI, or filtering the already-created view? There was a problem hiding this comment. Both, I'll add more details about "saved" vs. "unsaved". |
||
| - **Potential future features**: | ||
| - Improvements to what columns can be used for filters to support more complex use cases. | ||
|
|
||
| ## Sorting | ||
| - **For alpha release**: | ||
| - Users should be able to see what sorts are applied to their View. | ||
| - Users should be able to edit and delete sorts applied to their view, including basic use cases for columns that are not visible in the View. | ||
|
There was a problem hiding this comment. Same question as filters |
||
| - **Potential future features**: | ||
| - Improvements to what columns can be used for sorts to support more complex use cases. | ||
|
|
||
| ## Aggregations | ||
| - **For alpha release**: | ||
| - Users should be able to see what aggregations are applied to their View. | ||
| - Users should be able to edit and delete basic aggregations applied to their view (such as `DISTINCT` and `GROUP BY`) | ||
pavish marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| - **Potential future features**: | ||
| - Improvements to editing and deleting aggregations that support more complex use cases (such as `GROUPING SETS`) | ||
|
|
||
| ## Row Limit | ||
| - **For alpha release**: | ||
| - Users should be able to see if a row limit is applied. | ||
| - Users should be able to edit or delete a row limit if one is applied. | ||
| - **Potential future features**: | ||
| - Users should be able to add a row limit if none is applied. | ||
|
|
||
| ## Row Offset | ||
| - **For alpha release**: | ||
| - Users should be able to see if a row offset is applied. | ||
| - Users should be able to edit or delete a row offset if one is applied. | ||
| - **Potential future features**: | ||
| - Users should be able to add a row offset if none is applied. | ||
|
|
||
| ## Groups | ||
| - **For alpha release**: | ||
| - Views should support the same groupings as tables based on column data types. | ||
| - **Potential future features**: | ||
| - Additional grouping features based on data sources or data formula. | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,61 @@ | ||
| --- | ||
| title: Views: Mapping DB Queries to Views | ||
| description: | ||
| published: true | ||
| date: 2022-01-13T19:49:54Z | ||
| tags: | ||
| editor: markdown | ||
| dateCreated: 2022-01-13T19:49:54Z | ||
| --- | ||
|
|
||
| This page goes through the [PostgreSQL documentation about queries](https://www.postgresql.org/docs/14/queries.html) and maps various concepts listed there to our data model. We'll follow the structure of the PostgreSQL docs. | ||
|
|
||
| ## Table Expressions | ||
| See ["7.2 Table Expressions" on the PostgreSQL docs](https://www.postgresql.org/docs/14/queries-table-expressions.html) | ||
|
|
||
| | Clauses | Mapped To | Notes| | ||
| |-|-|-| | ||
| | `FROM` | "Data Sources" of columns | | | ||
| | `WHERE` | "Filters" | | | ||
| | `GROUP BY` & `HAVING` | "Aggregations" | | | ||
| | `GROUPING SETS`, `CUBE`, & `ROLLUP` | "Aggregations" | | | ||
| | Window function processing | "Data Formula" of columns | | | ||
|
|
||
| ## Select Lists | ||
| See ["7.3 Select Lists" on the PostgreSQL docs](https://www.postgresql.org/docs/14/queries-select-lists.html) | ||
|
|
||
| | Clauses | Mapped To | Notes| | ||
| |-|-|-| | ||
| | Select-List Items | Related to "Data Sources" of columns | | | ||
| | Column Labels | Used to determine column name in Views | | | ||
| | `DISTINCT` | "Aggregations" | | | ||
|
|
||
| ## Combining Queries | ||
|
|
||
| See ["7.4. Combining Queries (`UNION`, `INTERSECT`, `EXCEPT`)" on the PostgreSQL docs](https://www.postgresql.org/docs/14/queries-union.html) | ||
|
|
||
| There is no direct mapping of query combinations to the Views UI in Mathesar, since they are internal to the query. | ||
|
|
||
| They will only be visible when the user looks at the raw SQL query. | ||
|
|
||
| ## Sorting Rows | ||
| See ["7.5. Sorting Rows (`ORDER BY`)" on the PostgreSQL docs](https://www.postgresql.org/docs/14/queries-order.html) | ||
|
|
||
| This maps to View "Sorting". | ||
|
|
||
| ## LIMIT and OFFSET | ||
| See ["7.6. `LIMIT` and `OFFSET`" on the PostgreSQL docs"](https://www.postgresql.org/docs/14/queries-limit.html) | ||
|
|
||
| These map to View "Row Limit" and "Row Offset". | ||
|
|
||
| ## VALUES Lists | ||
| See: ["7.7 `VALUES` Lists" on the PostgreSQL docs"](https://www.postgresql.org/docs/14/queries-values.html) | ||
|
|
||
| These map to View column "Data Sources". They will show up as a computed source. | ||
|
|
||
| ## WITH Queries | ||
| See ["7.8. `WITH` Queries (Common Table Expressions)" on the PostgreSQL docs](https://www.postgresql.org/docs/14/queries-with.html) | ||
|
|
||
| There is no direct mapping of CTEs to the Views UI in Mathesar, since they are internal to the query. | ||
|
|
||
| They will only be visible when the user looks at the raw SQL query. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This isn't quite true. You could query a view, and further modify it (e.g., by adding filters, joining, choosing a subset of columns, etc.) without knowing how the view was created. This would give us some flexibility for working with views previously defined by some DB query.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I figured we'd be able to break down views previously defined by some DB query into the concepts defined in this spec (as long as we have access to the query, which I assume we would if we had access to the view). Is this inaccurate?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That might be possible, but would be very (very) difficult under all but the simplest circumstances. Moreover, my point is that even if we could do that, we don't need to in order to be able to work with a view. Having access to the underlying query isn't necessary, since we can treat a view as a table for any of the operations we support.