Perspective displays the prepared data， no calculation in perspective

[hengaini2055]

Since perspective cannot calculate complex data, it can only perform some simple calculations on a column, which is lacking in the current big data system environment. With the help of the current perspective function, can the data of dimension columns and measure values ​​on the database side be displayed in the form of a pivot table? Suppose, my data is: dimension column 1, dimension column 2, dimension column 3, measure value 1, measure value 2; I can prepare all the data of the combination through the [group by] and [rollup] functions on the database side. In this way, this data provides a pivot table, and all the data is displayed in three areas: row area, column area, and value area. Can such data be displayed in perspective? That is to say, the calculation of those measure values ​​is not on the client side, but on the server side; the client is only responsible for displaying it in the pivot table style and organizing it into a hierarchical structure.

[texodus]

Since perspective cannot calculate complex data, it can only perform some simple calculations on a column, which is lacking in the current big data system environment.

This is at best subjective. Regardless, if there's a use case or feature you're looking for, please raise a feature request for this.

Can such data be displayed in perspective? That is to say, the calculation of those measure values ​​is not on the client side, but on the server side;

Data architecture overview for Perspective
Server-only virtual architecture in Perspective
Loading data from a virtual table
Hosting a websocket virtual server in node.js
Hosting a websocket virtual server in python
Tutorial for a virtual Tornado-based python server
Rust/Axum virtual example
Python/tornado virtual streaming example
Python starlette virtual example
Python aiohttp virtual example
Node.js virtual streaming example

[hengaini2055]

such as this SQL statement:

SELECT 
    continent AS continent,
    country AS country,
    province AS province,
    SUM(revenue) AS total_revenue,
    SUM(revenvu)/sum(personNum)  AS avg_revenue_per_person --or more complex  measure
FROM sales_data
GROUP BY 
    continent,
    country,
    province
WITH ROLLUP;  -- get all hireachy combination of 

At the beginning, I thought that such a data set could be displayed in the perspective as a pivot table. However, there are still many issues that need to be addressed. For example, the measure function needs to be set to max, empty fields need to be changed to column subtotals, and dimension columns that are all empty are equivalent to totals or something. Also, if I only display two dimensions in the pivot table instead of all the dimensions, this also needs to be dealt with.

[texodus]

Such as this SQL

No repro so I can't answer precisely (and your pseudo sql has typos), but probably something like this

{
  "group_by": [
    "continent", "country", "province"
  ],
  "columns": [
    "continent", "country", "province", "total_revenue", "avg_revenue_per_person"
  ],
  "expressions": {
    "total_revenue": "\"revenue\"",
    "avg_revenue_per_person": "\"revenue\"",
  },
  "aggregates": {
    "avg_revenue_per_person": [
      "weighted mean",
      "personNum"
    ],
    "personNum": "count"
  }
}

Either way, we add trivial aggregates like this to the engine all the time e.g. #2930, especially when prompted by a thoughtful Feature Request ...

I'm not sure what the rest of your post means - at minimum you are fluctuating between some vocabulary terms we don't use in our documentation e.g. "measure", "column subtotal", "dimension" and "field" that I'm imprecise on what your expectation of the meaning is or what you're trying to accomplish ("or something"). The reason we ask to file a Feature request is to use the template as a guide for our discovery of what these details mean and how to address them, and it helps us prioritize work where there is actionable improvement to be made. If you want a serious answer to this question, please file a feature request with as much detail as possible.

[texodus]

please raise a feature request for this.

The reason we ask to file a Feature request is to use the template as a guide ...

especially when prompted by a thoughtful Feature Request ...

Locking since we seem to be having trouble following instructions. If you can see to it to whittle down what you're asking for to acceptable Feature Requests using the template, we'll comment there.