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

fix: cds failing tests #154

Merged
merged 23 commits into from
Aug 7, 2023
Merged

fix: cds failing tests #154

merged 23 commits into from
Aug 7, 2023

Conversation

BobdenOs
Copy link
Contributor

@BobdenOs BobdenOs commented Aug 4, 2023

Description

After investigating #153 I determined there are more breaking changes merged into main. As part of cleanup and refactor PRs. This PR contains fixes and analysis of why cds tests started to fail.

@BobdenOs
Copy link
Contributor Author

BobdenOs commented Aug 4, 2023

@stewsk In the recent change of cqn4sql the wildcard logic no longer include the generated foreign keys. While the cds tests expect them to be returned. Any suggestions ?

@stewsk
Copy link
Contributor

stewsk commented Aug 4, 2023

Hi @BobdenOs ,

In the recent change

which change are you referring to?

@@ -239,7 +239,8 @@ class CQN2SQLRenderer {
: SELECT.columns.map(x => {
const name = this.column_name(x)
// REVISIT: can be removed when alias handling is resolved properly
const d = elements[name] || elements[name.substring(1, name.length - 1)]
// REVISIT: for some reason not all elements are available in the elements list
const d = x.element || elements[name]
Copy link
Contributor

Choose a reason for hiding this comment

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

Better than before, anyways, but...

  • x.element should always be defined, and the fallback never required
  • q.elements should contain all expected elements definitions ac cording to the result set type

Copy link
Contributor Author

Choose a reason for hiding this comment

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

x.element does not exist when x is an expand sub select.

Copy link
Contributor

Choose a reason for hiding this comment

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

Does an entry for that exist in q.elements? → then x.element should exist as well and be the same

Comment on lines +644 to +645
// SELECT.from() does not accept joins
select.SELECT.from = from
Copy link
Contributor

Choose a reason for hiding this comment

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

Why do we see joins here?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We get a join when streaming from draft entities. between *.drafts and DraftAdministrativeData.

Comment on lines 833 to 834
// Column names like "Order" clash with "ORDER" keyword so toUpperCase is required
if (s.toUpperCase() in this.class.ReservedWords || /^\d|[$' ?@./\\]/.test(s)) return '"' + s + '"'
Copy link
Contributor

Choose a reason for hiding this comment

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

Better add the capitalised casing to ReservedWords

Comment on lines +186 to +188
Timestamp: e => `ISO(${e})`,
// REVISIT: generic-virtual.test.js expects now to be returned as ISO string
// test 'field with current timestamp is correctly formatted' fails otherwise
Copy link
Contributor

Choose a reason for hiding this comment

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

Lets fix this test please

Comment on lines 196 to 197
Float: expr => `nullif(quote(${expr}),'NULL')->'$'`,
Double: expr => `nullif(quote(${expr}),'NULL')->'$'`,
Copy link
Contributor

Choose a reason for hiding this comment

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

Shouldn't we keep these out as before and discussed?

@danjoa
Copy link
Contributor

danjoa commented Aug 5, 2023

Replaced fuzzyKeys as that seemed too much and with strange output:

> fuzzyKeys('Order')
{
  Order: 1,
  order: 1,
  'O�der': 1,
  'o�der': 1,
  'Or�er': 1,
  'or�er': 1,
  'O��er': 1,
  'o��er': 1,
  'Ord�r': 1,
  'ord�r': 1,
  'O�d�r': 1,
  'o�d�r': 1,
  'Or��r': 1,
  'or��r': 1,
  'O���r': 1,
  'o���r': 1,
  'Orde�': 1,
  'orde�': 1,
  'O�de�': 1,
  'o�de�': 1,
  'Or�e�': 1,
  'or�e�': 1,
  'O��e�': 1,
  'o��e�': 1,
  'Ord��': 1,
  'ord��': 1,
  'O�d��': 1,
  'o�d��': 1,
  'Or���': 1,
  'or���': 1,
  'O����': 1,
  'o����': 1
}

@danjoa danjoa enabled auto-merge (squash) August 5, 2023 11:09
@BobdenOs
Copy link
Contributor Author

BobdenOs commented Aug 5, 2023

fuzzyKeys was build with the expectation that all keywords where provided in uppercase.

My understanding is that the number of keys on an object should negatively impact the key lookup speed. That is why I added the question mark.

My main concern with only having reasonable keys in the map is that the behaviour is different from having the check be case insensitive. So adding a secondary case insensitive check would be required to maintain functional consistency.

@BobdenOs
Copy link
Contributor Author

BobdenOs commented Aug 5, 2023

Current issue is that * sometimes does not include foreign keys. My understanding is that * should not include any generated foreign key columns. But the current tests expect all foreign key columns to be included.

@stewsk
Copy link
Contributor

stewsk commented Aug 7, 2023

I think that * should include the foreign keys. When having a managed association in the select list, the respective foreign key(s) should be respected, and a * includes also the managed associations.
In which situation does * currently not include the FKs?

@BobdenOs
Copy link
Contributor Author

BobdenOs commented Aug 7, 2023

When someone combines * and expand. The foreign key of the expand is not returned as a flat column anymore.

I fixed this issue here , but this makes all the cqn4sql tests fail.

@stewsk
Copy link
Contributor

stewsk commented Aug 7, 2023

Just to avoid that we misunderstand each other: can you provide an example for what the select looks like, what you expect it should do, and what it actually does (currently)?

@BobdenOs
Copy link
Contributor Author

BobdenOs commented Aug 7, 2023

Sure here are all the scenarios:

simple

input:

select * from Books

output:

select ID, tittle, descr, author_ID, genre_ID from Books

with expand

input:

select *, author { * } from Books

output:

select 
  ID,
  tittle,
  descr,
  (select ID, name from Author where Author.ID = Books.author_ID) as author,
  genre_ID
from Books

expected:

select 
  ID,
  tittle,
  descr,
  (select ID, name from Author where Author.ID = Books.author_ID) as author,
  author_ID, -- this column is currently missing
  genre_ID
from Books

@stewsk
Copy link
Contributor

stewsk commented Aug 7, 2023

Ok, I see.
I would say: works as designed. The reasoning for the current behavior is:
Selecting author { * } results in a structured thing called author.
Now there is the "smart *" mechanism, which implicitly "removes" all elements from the * that are also explicitly selected - otherwise that would lead to duplicate names in the result. This mechanism operates before the flattening and it operates on the names in the result set. So in

select from Books { *, author }

the author is implicitly removed from the *, as it is explicitly selected.
And the same happens for

select from Books { *, author { * } }

as the effective/resulting name of author {*} is author.

If you wrote

select from Books { *, author as a { * } } 

then you would get the foreign key from the *

@danjoa danjoa merged commit d2bd96e into main Aug 7, 2023
@danjoa danjoa deleted the fix-cds-tests branch August 7, 2023 10:01
@stewsk
Copy link
Contributor

stewsk commented Aug 7, 2023

@patricebender - we need to have a detailed look at this when you are back.
The smart "*" is intended to avoid duplicates in the inferred elements list. In the situation described by Bob above there apparently is no such conflict - at least for flat access. We should check however, that the latest fix did not introduce problems in other situations.

patricebender added a commit that referenced this pull request Aug 17, 2023
this reverts the cqn4sql part of the hotfix in #154

---

The problem was, that in a flat model, the foreign keys were not part of the result anymore, in case that the respective association was overwritten by the smart wildcard mechanism. E.g. by an expand.

The reason was, that in case of a flat model, we skipped the foreign keys and still flattened the association. This caused the bug where overwritting an association caused the lack of the foreign key
in the result.

The fix here is simple, skip the association from the wildcard expansion instead. The compiler already, correctly generated the foreign key elements for us.
patricebender added a commit that referenced this pull request Aug 23, 2023
…ode (#176)

* cqn4sql: skip assocs from wildcard expansion instead of fks in flat mode

this reverts the cqn4sql part of the hotfix in #154

---

The problem was, that in a flat model, the foreign keys were not part of the result anymore, in case that the respective association was overwritten by the smart wildcard mechanism. E.g. by an expand.

The reason was, that in case of a flat model, we skipped the foreign keys and still flattened the association. This caused the bug where overwritting an association caused the lack of the foreign key
in the result.

The fix here is simple, skip the association from the wildcard expansion instead. The compiler already, correctly generated the foreign key elements for us.

* adapt test description

* no debug

* Update db-service/test/cqn4sql/wildcards.test.js

Co-authored-by: Steffen Weinstock <[email protected]>

---------

Co-authored-by: Steffen Weinstock <[email protected]>
@cap-bots cap-bots mentioned this pull request Jul 18, 2024
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

Successfully merging this pull request may close these issues.

3 participants