-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Product spec for Views #22
Changes from 5 commits
4f711ea
a634ef0
49149f1
a3af069
1b15c78
91e8fac
28a8baf
35e2683
dd659bb
062bd76
494f1cd
2a59099
6ca5c8d
ce3941b
f6b26e9
cc4e6d0
601ae44
bde64db
500bd75
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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,90 @@ | ||
--- | ||
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 backend and API. Each heading represents an attribute of Views. | ||
|
||
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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Hierarchy and composition are the reason why I would not call them saved filters. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @silentninja said
This is a succinct way to put it; I agree. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
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 | | ||
|
||
**Note**: This only describes what's stored at the View query level. The UI will allow additional filtering that is not "saved" to the query. | ||
|
||
## 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 | | ||
|
||
**Note**: This only describes what's stored at the View query level. The UI will allow additional sorting that is not "saved" to the query. | ||
|
||
## 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 | | ||
|
||
**Note**: This only describes what's stored at the View query level. The UI will allow additional aggregations that are not "saved" to the query. | ||
|
||
## 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,43 @@ | ||
--- | ||
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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. | ||
|
||
### 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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Will it be just referring to the parent of view ignoring the ancestors? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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) | ||
|
||
Using Element's UI as an example (Matrix channel names stand in for data sources here), here's how Sources might be represented: | ||
|
||
![Sources image](/assets/product/specs/2022-01-views/03-modeling-view-columns/Screen Shot 2022-01-20 at 4.23.21 PM.png Shot 2022-01-20 at 4.21.05 PM.png) | ||
|
||
### Formula | ||
- **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. | ||
|
||
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. | ||
|
||
Using Element's UI as an example (Matrix channel names stand in for data sources here), here's how a Formula might be represented. Note that Sources are used within the Formula. | ||
|
||
![Sources image](/assets/product/specs/2022-01-views/03-modeling-view-columns/Screen Shot 2022-01-20 at 4.23.21 PM.png Shot 2022-01-20 at 4.23.21 PM.png) | ||
|
||
### Link | ||
- **Definition**: This notes whether a column is a join column. This is a column used to match the same values across multiple tables to create the View. These columns have multiple Sources but no Formula. | ||
- **Allowed values**: True or False. | ||
- **Required**: This must be set for all columns. | ||
|
||
In [this example View](https://www.w3resource.com/sql/creating-views/create-view-with-join.php), the `agent_code` and `cust_code` columns are Links. |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,100 @@ | ||
--- | ||
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. | ||
|
||
# Interacting with Views | ||
This covers functionality for Views that have already been created. | ||
|
||
## 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) | ||
- Sources (non-editable, set when adding a new column to a View) | ||
- Formula (non-editable, set when adding a new column to a View) | ||
- Link (non-editable, set when adding a new column to a View) | ||
- **Potential future features**: | ||
- Show virtual columns involved in view creation (via CTEs, subqueries, etc.) | ||
- Allow editing formula through UI | ||
- Allow using SQL to edit formula | ||
|
||
## 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. The entire record should be edited through a form, not just the single item. | ||
- "Direct representation" means that the record has only one data source and no formula. | ||
- If a column is a direct representation of a record, users should be able to add a new record of the same type via the View UI. | ||
- **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 in the UI, including basic use cases for columns that are not visible in the View. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What does "including basic use cases for columns that are not visible in the View" mean? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Assuming |
||
- By default, these filters are not saved to the database. | ||
- Users should be able to save filters applied to the View in the UI. | ||
- Under the hood, this will create a new View with an updated query and delete the old View. In the UI, this will appear as if the View has been updated. | ||
- **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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Same question as filters |
||
- By default, these sorts are not saved to the database. | ||
- Users should be able to save sorts applied to the View in the UI. | ||
- Under the hood, this will create a new View with an updated query and delete the old View. In the UI, this will appear as if the View has been updated. | ||
- **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
|
||
- By default, these aggregations are not saved to the database. | ||
- Users should be able to save aggregations applied to the View in the UI. | ||
- Under the hood, this will create a new View with an updated query and delete the old View. In the UI, this will appear as if the View has been updated. | ||
- **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. This should save directly to the database. | ||
- **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. This should save directly to the database. | ||
- **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. | ||
- Groups cannot be saved to the database. | ||
- **Potential future features**: | ||
- The ability to save groups as part of a view. This will only work within the Mathesar UI, not at the DB level. | ||
- Additional grouping features based on data sources or data formula. | ||
|
||
# View Setup | ||
This covers functionality for creating Views or adding new columns to an existing View. | ||
|
||
`TODO` |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,62 @@ | ||
--- | ||
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` | "Sources" of columns | | | ||
| `WHERE` | "Filters" | | | ||
| `GROUP BY` & `HAVING` | "Aggregations" | | | ||
| `GROUPING SETS`, `CUBE`, & `ROLLUP` | "Aggregations" | | | ||
| Window function processing | "Formula" of columns | | | ||
| Join columns | "Link" 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 "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 "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.