How many issues can be potentially stored on a Jira instance? Millions, of course. So, do you realize how much reckless would be running this query?!
Imagine how much information the engine needs to process in order to run this query.
| Code Block | ||
|---|---|---|
| ||
select * from ISSUE |
It does not make any sense allowing users to run such reckless querieswill take a lot of time to execute all issues available, the engine will process numerous “calls” to Jira and as a result, we gonna face “informational congestion”. So the app introduces some column constraints to avoid them:
...
Many built-in tables (AKA as dynamic tables) require some values to work. This might result seem a bit annoying for users not used to this behavior at the beginning.
...
| Code Block | ||
|---|---|---|
| ||
show columns from ISSUE |
...
Full A full scanof numerous built-in tables are is not allowed. Full scan means that the SQL engine requires to read all the data from the table to resolve the user’s query. This is not optimal and it may cause productivity and other reliability issues of for the Jira server or user’s browser. As mentioned, the engine introduces the concept of column constraints to force user users to set a limited scope for the table data, and the query will be aborted with a full scan error raised by the engine if a full scan is detected on a constrained dynamic table.
How to run a query against a constrained table? Simple: provide values for the required constrained columns. This can be done via where WHERE clause or join JOIN conditions as shown in the example below:
...