Skip to content
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

Open
wants to merge 70 commits into
base: development
Choose a base branch
from
Open

Conversation

dahfjkg
Copy link
Contributor

@dahfjkg dahfjkg commented Oct 4, 2024

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

content/en/docs/refguide/modeling/data/oql/oql-clauses.md Outdated Show resolved Hide resolved
content/en/docs/refguide/modeling/data/oql/oql-clauses.md Outdated Show resolved Hide resolved
content/en/docs/refguide/modeling/data/oql/oql-clauses.md Outdated Show resolved Hide resolved
content/en/docs/refguide/modeling/data/oql/oql-clauses.md Outdated Show resolved Hide resolved
content/en/docs/refguide/modeling/data/oql/oql-clauses.md Outdated Show resolved Hide resolved
content/en/docs/refguide/modeling/data/oql/oql-clauses.md Outdated Show resolved Hide resolved
content/en/docs/refguide/modeling/data/oql/oql-clauses.md Outdated Show resolved Hide resolved
content/en/docs/refguide/modeling/data/oql/oql-clauses.md Outdated Show resolved Hide resolved
content/en/docs/refguide/modeling/data/oql/oql-clauses.md Outdated Show resolved Hide resolved
content/en/docs/refguide/modeling/data/oql/oql-clauses.md Outdated Show resolved Hide resolved
Copy link
Collaborator

@MarkvanMents MarkvanMents left a 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.


### `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.
Copy link
Collaborator

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?

Copy link
Collaborator

@MarkvanMents MarkvanMents left a 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?

Copy link
Collaborator

@MarkvanMents MarkvanMents left a 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!

@CLAassistant
Copy link

CLAassistant commented Oct 21, 2024

CLA assistant check
All committers have signed the CLA.

Copy link
Collaborator

@MarkvanMents MarkvanMents left a 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:

Copy link
Collaborator

@MarkvanMents MarkvanMents left a 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.

Comment on lines 34 to 39
```sql
SELECT COUNT(*)
FROM Module.Person AS P
JOIN Module.Person/Module.Person_City/Module.City AS C
GROUP BY C/Name
```
Copy link
Collaborator

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?

Copy link
Contributor

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.

Comment on lines +95 to +97
SELECT COUNT(*)
FROM Module.Person
WHERE Module.Person/City = Module.City/Name
Copy link
Collaborator

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?

Copy link
Contributor

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.

Copy link
Contributor

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.

Copy link
Contributor

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.

Comment on lines +1042 to +1044
SELECT COUNT(*)
FROM Sales.Customer AS Cust
WHERE Cust/LastName = Req/CustomerName
Copy link
Collaborator

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AS needed.

Copy link
Contributor

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

Comment on lines +1211 to +1212
SELECT COUNT(*)
FROM Sales.Location
Copy link
Collaborator

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same asnwer; AS needed.

Copy link
Contributor

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.


`expression` specifies the expression to convert.

##### data_type
Copy link
Contributor

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.

Copy link
Collaborator

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.

Copy link
Contributor

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 ?

Copy link
Contributor

@passalaqua passalaqua Nov 27, 2024

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.

Copy link
Contributor Author

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me!

Copy link
Contributor

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?

Copy link
Contributor Author

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

Copy link
Contributor

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.


## 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.
Copy link
Contributor

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...)

@sbont sbont mentioned this pull request Dec 11, 2024
@@ -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.
Copy link
Contributor

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%)?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pushed an update

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants