-
Notifications
You must be signed in to change notification settings - Fork 726
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
Documentation for OQL #8431
base: development
Are you sure you want to change the base?
Documentation for OQL #8431
Conversation
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.
Part way through the review
Just noting here that I've moved the document to match the structure we discussed in Confluence. Will continue working on this tomorrow.
content/en/docs/refguide/modeling/domain-model/oql/oql-clauses.md
Outdated
Show resolved
Hide resolved
|
||
### `SELECT` clause | ||
|
||
The `SELECT` clause specifies which entity attributes or other specified data must be retrieved. The `SELECT` clause consists of the term `SELECT` and one or more expressions. Each expression must be separated by a comma. Each expression defines a column in the result. Each expression can have an alias, which will be the name of the column in the result. |
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.
You say that you have SELECT
plus expressions. However, you explain these expressions in this document, not in the OQL Expressions document. I think this is a bit confusing - is there another word we can use (sub-clauses, or definitions?) instead of expressions here?
Also, you say that Each expression defines a column in the result. However, the *
expression defines multiple columns in the result, doesn't it?
content/en/docs/refguide/modeling/domain-model/oql/oql-clauses.md
Outdated
Show resolved
Hide resolved
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.
Hi @dahfjkg and @pijuskri
I have done some proofreading in these commits: https://github.com/mendix/docs/pull/8431/files/8786adfd64abf1412b116d6433dd8457a11e7712..239aebdb960b3c3a018fedc47c43b47f5021afb3.
I have also made various suggestions in some comments.
Can you have a look at what I've done so far and see if you think I'm on the right track. We can discuss it further in a call if we need to discuss my changes.
If any of your earlier discussions are resolved can you mark them as resolved so it is clear what is still to do?
content/en/docs/refguide/modeling/domain-model/oql/oql-clauses.md
Outdated
Show resolved
Hide resolved
content/en/docs/refguide/modeling/domain-model/oql/oql-clauses.md
Outdated
Show resolved
Hide resolved
content/en/docs/refguide/modeling/domain-model/oql/oql-clauses.md
Outdated
Show resolved
Hide resolved
content/en/docs/refguide/modeling/domain-model/oql/oql-clauses.md
Outdated
Show resolved
Hide resolved
content/en/docs/refguide/modeling/domain-model/oql/oql-clauses.md
Outdated
Show resolved
Hide resolved
content/en/docs/refguide/modeling/domain-model/oql/oql-clauses.md
Outdated
Show resolved
Hide resolved
content/en/docs/refguide/modeling/domain-model/oql/oql-clauses.md
Outdated
Show resolved
Hide resolved
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.
Got a bit further, but still have only got as far as JOIN.
Sorry this is taking so long - need to do other things at the same time!
content/en/docs/refguide/modeling/domain-model/oql/oql-clauses.md
Outdated
Show resolved
Hide resolved
content/en/docs/refguide/modeling/domain-model/oql/oql-clauses.md
Outdated
Show resolved
Hide resolved
content/en/docs/refguide/modeling/domain-model/oql/oql-clauses.md
Outdated
Show resolved
Hide resolved
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.
Hi there,
I've nearly finished my review. Sorry it is taking so long, but I keep being called away to do other things.
I have a couple more questions which are related to parts of the text. See below:
content/en/docs/refguide/modeling/domain-model/oql/oql-clauses.md
Outdated
Show resolved
Hide resolved
content/en/docs/refguide/modeling/domain-model/oql/oql-clauses.md
Outdated
Show resolved
Hide resolved
content/en/docs/refguide/modeling/domain-model/oql/oql-clauses.md
Outdated
Show resolved
Hide resolved
Co-authored-by: Mark van Ments <[email protected]>
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.
Reviewed for COUNT (*) as discussed on Slack.
```sql | ||
SELECT COUNT(*) | ||
FROM Module.Person AS P | ||
JOIN Module.Person/Module.Person_City/Module.City AS C | ||
GROUP BY C/Name | ||
``` |
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.
Will this work, or does COUNT(*) need an AS?
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.
It will need an AS
.
SELECT COUNT(*) | ||
FROM Module.Person | ||
WHERE Module.Person/City = Module.City/Name |
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.
Will this work, or does COUNT(*) need an AS?
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.
Same here; requires AS
, because otherwise COUNT(*)
would be a nameless column.
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.
AS
is not required here, the column name will be the alias of the subquery PersonCount
, the internal subquery column name has no effect on the main queries column names.
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.
Thanks. I missed the fact that it was nested from the diff.
SELECT COUNT(*) | ||
FROM Sales.Customer AS Cust | ||
WHERE Cust/LastName = Req/CustomerName |
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.
Will this work, or does COUNT(*) need an AS?
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.
AS
needed.
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.
AS
is not required, same reason as other case with subquery in attribute
SELECT COUNT(*) | ||
FROM Sales.Location |
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.
Will this work, or does COUNT(*) need an AS?
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.
Same asnwer; AS
needed.
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.
AS
is not required, HAVING
and WHERE
are not affected by changes to mandatory column names. It only applies to the main SELECT
query and the attributes/columns of it.
Extra information for union clause
content/en/docs/refguide/modeling/domain-model/oql/oql-clauses.md
Outdated
Show resolved
Hide resolved
|
||
`expression` specifies the expression to convert. | ||
|
||
##### data_type |
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.
We still support CAST to FLOAT (and FLOAT is still a valid keyword in OQL). We have only deprecated it as a valid result type for queries, but intermediate calculations should still work.
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.
Deprecated or removed entirely?
Is FLOAT deprecated (will it go in Mx 11, for example). I can't really see any point in keeping it if we have DECIMAL.
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.
Is there a use case for a new user of OQL to use FLOAT
instead of DECIMAL
?
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.
Deprecated or removed entirely?
As I said:
We have only deprecated it as a valid result type for queries, but intermediate calculations should still work.
And indeed, we still have tests for it and it still works, AFAICS.
Either we document here or in the list of keywords, but completely omitting mentioning something that would otherwise break your query if you use as an identifier is not a good idea, IMO. I just wrote the comment here because CAST
is the only place I remember still accepts FLOAT
.
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 pushed a mention of FLOAT
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.
Looks good to me!
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.
Wouldn't a better place for the mention of FLOAT
be in the CAST
section, given that is the only valid use case?
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.
If we are to move away from Float, I'd not mention any use cases of it at all
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.
Sorry, I reread Augusto's comment. Given the reason to mention it is to explain why its a keyword, then the current placement is good. Nothing else needs to be added.
…o pr/dahfjkg/8431
|
||
## Introduction | ||
|
||
In Studio Pro version 10.17, we introduced OQL v2. You will have to switch to OQL v2 in order to enable View entities. See the [View entities](/refguide/app-settings/#enable-view-entities) app setting for more information. |
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.
Note that we've renamed this setting to "OQL version 2", and the anchor will be #oql-version-2.
See also our branch for View Entities at development...sbont:docs:dux-1-view-entities
(Also, I assume you might want to update the Studio Pro release version...)
@@ -58,14 +58,16 @@ There is no direct support for `DATETIME` literals. For functions that take `DAT | |||
|
|||
## System variables | |||
|
|||
XPath [system variables](/refguide/xpath-keywords-and-system-variables/) can be used in OQL with the format: | |||
Most XPath [system variables](/refguide/xpath-keywords-and-system-variables/#system-variables) can be used in OQL with the format: | |||
|
|||
```sql | |||
'[%SystemVariable%]' | |||
``` | |||
|
|||
These variables can be used the same way as other expressions. |
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.
To be more explicit, we should mention that system variables like %CurrentUser%
are resolved to id's of objects with corresponding type (LONG
?). Same with date system variables, are they just strings? How do intervals work (like %DayLength%
)?
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.
Pushed an update
This is the documentation for OQL following the new structure.
It contains the original Clauses PR and changes from OQL expressions and OQL expression syntax