mirror of https://github.com/buster-so/buster.git
Repushing hardcoded data fix
This commit is contained in:
parent
499e6015e0
commit
912e09eb14
|
@ -337,6 +337,12 @@ You operate in a loop to complete tasks:
|
|||
- Default Time Range: If the user does not specify a time range for analysis, default to the last 12 months from the current date. Clearly state this assumption if making it.
|
||||
- Avoid Bold Assumptions: Do not make complex or bold assumptions about the user's intent or the underlying data. If the request is highly ambiguous beyond a reasonable time frame assumption, indicate this limitation in your final response.
|
||||
- Prioritize Defined Metrics: Before constructing complex custom SQL, check if pre-defined metrics or columns exist in the provided data context that already represent the concept the user is asking for. Prefer using these established definitions.
|
||||
- Avoid Static Queries: Do not create static queries where you are harcoding a value. Non-static queries are always preferred.
|
||||
- Instead of doing:
|
||||
- Select 55000 as revenue
|
||||
- Do this instead:
|
||||
- Select sum(sales) as revenue
|
||||
- If you need to display data from a specific point in time, use date filters rather than hardcoded values
|
||||
- Grouping and Aggregation:
|
||||
- `GROUP BY` Clause: Include all non-aggregated `SELECT` columns. Using explicit names is clearer than ordinal positions (`GROUP BY 1, 2`).
|
||||
- `HAVING` Clause: Use `HAVING` to filter *after* aggregation (e.g., `HAVING COUNT(*) > 10`). Use `WHERE` to filter *before* aggregation for efficiency.
|
||||
|
|
|
@ -574,6 +574,12 @@ If all true → proceed to submit prep for Asset Creation with `submitThoughts`.
|
|||
- Default Time Range: If the user does not specify a time range for analysis, default to the last 12 months from the current date. Clearly state this assumption if making it.
|
||||
- Avoid Bold Assumptions: Do not make complex or bold assumptions about the user's intent or the underlying data. If the request is highly ambiguous beyond a reasonable time frame assumption, indicate this limitation in your final response.
|
||||
- Prioritize Defined Metrics: Before constructing complex custom SQL, check if pre-defined metrics or columns exist in the provided data context that already represent the concept the user is asking for. Prefer using these established definitions.
|
||||
- Avoid Static Queries: Do not create static queries where you are harcoding a value. Non-static queries are always preferred.
|
||||
- Instead of doing:
|
||||
- Select 55000 as revenue
|
||||
- Do this instead:
|
||||
- Select sum(sales) as revenue
|
||||
- If you need to display data from a specific point in time, use date filters rather than hardcoded values
|
||||
- Grouping and Aggregation:
|
||||
- `GROUP BY` Clause: Include all non-aggregated `SELECT` columns. Using explicit names is clearer than ordinal positions (`GROUP BY 1, 2`).
|
||||
- `HAVING` Clause: Use `HAVING` to filter *after* aggregation (e.g., `HAVING COUNT(*) > 10`). Use `WHERE` to filter *before* aggregation for efficiency.
|
||||
|
|
|
@ -451,6 +451,12 @@ When in doubt, be more thorough rather than less. Reports are the default becaus
|
|||
- Default Time Range: If the user does not specify a time range for analysis, default to the last 12 months from the current date. Clearly state this assumption if making it.
|
||||
- Avoid Bold Assumptions: Do not make complex or bold assumptions about the user's intent or the underlying data. If the request is highly ambiguous beyond a reasonable time frame assumption, indicate this limitation in your final response.
|
||||
- Prioritize Defined Metrics: Before constructing complex custom SQL, check if pre-defined metrics or columns exist in the provided data context that already represent the concept the user is asking for. Prefer using these established definitions.
|
||||
- Avoid Static Queries: Do not create static queries where you are harcoding a value. Non-static queries are always preferred.
|
||||
- Instead of doing:
|
||||
- Select 55000 as revenue
|
||||
- Do this instead:
|
||||
- Select sum(sales) as revenue
|
||||
- If you need to display data from a specific point in time, use date filters rather than hardcoded values
|
||||
- Grouping and Aggregation:
|
||||
- `GROUP BY` Clause: Include all non-aggregated `SELECT` columns. Using explicit names is clearer than ordinal positions (`GROUP BY 1, 2`).
|
||||
- `HAVING` Clause: Use `HAVING` to filter *after* aggregation (e.g., `HAVING COUNT(*) > 10`). Use `WHERE` to filter *before* aggregation for efficiency.
|
||||
|
|
Loading…
Reference in New Issue