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

Support Unpartitioned Analytic Invocation #520

Open
noahboerger opened this issue Oct 21, 2024 · 2 comments
Open

Support Unpartitioned Analytic Invocation #520

noahboerger opened this issue Oct 21, 2024 · 2 comments

Comments

@noahboerger
Copy link

UM 189 partitionClause

Issue Description

The partitionClause is defined in the reference manual 2.1 (p. 189) as partitionClause ::= partition by identifier { , identifier }* with the additional description of the default being If the clause is omitted, then the Data Set is partitioned by the Identifier Components that are not specified in the orderClause.

Therefore it is currently not possible to perform an analytic invocation without partitioning.

Proposed Solution

Support partitionClause without specifing any identifier or set the default when omitting the partitioningClause to this behaviour, to allow analytic invocations on unpartitioned datasets.

Example

When ds1 is

id_1 id_2 id_3 val
IDENTIFIER IDENTIFIER IDENTIFIER MEASURE
INTEGER INTEGER INTEGER INTEGER
1 1 1 1
1 1 2 1
1 2 1 1
2 1 1 1
2 2 1 1
2 2 2 1
3 1 1 1
3 2 1 1
3 2 2 1

The result of ds2 := ds1[calc rank_col := rank(over(order by id_1))]; or ds2 := ds1[calc rank_col := rank(over(partition by order by id_1))]; should be out of my point of view

id_1 id_2 id_3 val rank_col
IDENTIFIER IDENTIFIER IDENTIFIER MEASURE MEASURE
INTEGER INTEGER INTEGER INTEGER INTEGER
1 1 1 1 1
1 1 2 1 1
1 2 1 1 1
2 1 1 1 4
2 2 1 1 4
2 2 2 1 4
3 1 1 1 7
3 2 1 1 7
3 2 2 1 7

but currently is (because of the default partitioning / not supported gramatic to have a partitionClause without specifying any identifier)

id_1 id_2 id_3 val rank_col
IDENTIFIER IDENTIFIER IDENTIFIER MEASURE MEASURE
INTEGER INTEGER INTEGER INTEGER INTEGER
1 1 1 1 1
1 1 2 1 1
1 2 1 1 1
2 1 1 1 2
2 2 1 1 2
2 2 2 1 1
3 1 1 1 3
3 2 1 1 3
3 2 2 1 2
@antonio-olleros
Copy link

I agree, this seems like a limitation of the language, because it is not possible to get a result that may need to be calculated

@linardian
Copy link
Collaborator

Hi @noahboerger. First of all (sorry, but) I do not understand the results you are expecting, so if you can please elaborate a little bit more on this I would be very grateful. Secondly, the behaviour of the operator is exactly the one adopted by RDBMS (I made a test with ORACLE and DB2). Thank you so much.

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

No branches or pull requests

3 participants