select * from PROJECT

will work.

Whereas

select * from project

will not.

We use the following convention for the table names:

• No prefix: Jira WorkCore

• SF_ prefix: Jira Software

• SM_ prefix: Jira Service ManagerManagement

This can cause series reliability problems and compromise the Jira server instance performance.

A clear example is:

SELECT * FROM ISSUE

What if there are millions of records/issues?

Therefore many queries performing full scans on tables are aborted by the SQL Cloud engine by raising a Full Scan error:

Since SQL Cloud is a wrapper for the Atlassian’s Jira public REST API, it relies on the underlaying Atlassian’s API for that. In other words, if the Jira REST API allows querying for all the results (i.e.: PROJECTs), then SQL Cloud will allow it too. Otherwise (i.e.: ISSUEs) not. In this case the indexed column names are displayed (JQL and ID in the example above).

An indexed column in SQL Cloud corresponds to a filter parameter required by the Atlassian’s Jira public REST API to fetch data from Jira. For instance, you can search for issues in Jira by ID or by JQL query.

In general, the SQL Cloud is an straightforward implementation of the Jira REST API and inherits the same security and the rest of the constraints.

These are the rules for conditions resolution:

1. The table in FROM clause will get the conditions from the WHERE clause directly

2. The rest of the tables will take them from the JOIN ON conditions only.

In other words: (order of execution)

1. WHERE conditions will be applied only to the table only (FROM) at the beginning of the query resolution.

2. Next, JOINs will be resolved taking only ON conditions into consideration (WHERE conditions will be ignored at this stage)

3. The rest of the WHERE conditions will be applied after all the JOINS have been resolved

NOTE: A lot of database vendors work in a different way as they support extra query optimizations based on indexes, etc. They analyze the query syntax and some optimizations are applied in a sort of query internal re-writing before the execution starts. Thus, the users do not know the exact way how their queries will be really resolved and many of those database vendors provide an EXPLAIN command to show the real execution order to the user.

In SQL Cloud, queries are executed in the exact order described above. It is for that reason that is very important to understand the right execution order of all the conditions (WHERE and JOINS). This might result confusing for a lot of users used to popular databases supporting those internal re-writing optimizations and expecting the same behavior here. In fact, the SQL specs are agnostic in regard to how the engine will resolve the query since it is supposed that tables have records which is not true in SQL Cloud as all the bales are empty an populated in real time to answer the users' queries. Therefor users must instruct the engine about the right order to populate the tables, via the SQL query syntax.

Please pay attention to the having condition: count(*) > 2

SELECT `i`.`KEY`as `Issue`, count(*) as `Num. comments`
FROM ISSUE `i`
LEFT JOIN ISSUECOMMENT `ic` ON `ic`.`ISSUEID` = `i`.`ID`
WHERE `i`.`JQL` = 'PROJECT = TALH'
GROUP BY `i`.`KEY`
HAVING count(*) > 2

Works!

In this query the condition has been modified to uses column aliases: `Num. comments` > 2

SELECT `i`.`KEY`as `Issue`, count(*) as `Num. comments`
FROM ISSUE `i`
LEFT JOIN ISSUECOMMENT `ic` ON `ic`.`ISSUEID` = `i`.`ID`
WHERE `i`.`JQL` = 'PROJECT = TALH'
GROUP BY `i`.`KEY`
HAVING `Num. comments` > 2

Not works!