scottmarlow
commented
1 year ago The 522 failing TCK tests are shown in the attached jtrfiles.zip although not all of the test results show the deployment failure.
Open scottmarlow opened 1 year ago
scottmarlow
commented
1 year ago The 522 failing TCK tests are shown in the attached jtrfiles.zip although not all of the test results show the deployment failure.
scottmarlow
commented
1 year ago @lukasj could you please add the challenge label to this issue. Thank you!
lukasj
commented
1 year ago @scottmarlow try to employ <details> element when pasting large codeblocks/stacktraces (how to is ie here) to make reports more readable and requiring less scrolling
scottmarlow
commented
1 year ago @scottmarlow try to employ
<details>element when pasting large codeblocks/stacktraces (how to is ie here) to make reports more readable and requiring less scrolling
Thanks @lukasj , I pasted an example failure here.
scottmarlow
commented
1 year ago 
sebersole
commented
1 year ago If not clear from Scott's description, the concern is mapping those array types when Character[] and Byte[] types may contain null elements, unlike their primitive counterparts. Because of this nullness aspect, providers have a choice to make when it comes to mapping them as (VAR)CHAR and (VAR)BINARY are not viable options.
The TCK cheats a bit by using all non-null elements. Honestly, since null elements are perfectly legal as elements in these types, the TCK should also test that scenario if it is testing them at all.
Why does this matter? E.g. in Hibernate we decided to map these to SQL ARRAY which in our opinion makes the most sense. However, not all databases support SQL ARRAY. E.g. we certify using Derby which does not.
Not to mention the discussion about the usefulness of Character[] and/or Byte[] at all. The spec does explicitly say these are supported, so we clearly need to support them. We just don't think that providers that map these to SQL ARRAY (which we argue is the most natural mapping to account for nullness) should be penalized, considering not all databases support SQL ARRAY types.
scottmarlow
commented
1 year ago @lukasj Pending approval of this TCK challenge, we will release updated TCKs as per discussion on https://github.com/jakartaee/platform-tck/pull/1165 to be had. Feedback on the pr is welcome about the TCK change which IMO is independent of accepting the TCK challenge.
dmatej
commented
1 year ago Wouldn't be good also to create an issue for Derby? It is quite old, but now it is much easier to fix/improve something.
scottmarlow
commented
1 year ago Wouldn't be good also to create an issue for Derby? It is quite old, but now it is much easier to fix/improve something.
If anyone wants to open a jirai, looks like email has to be sent to gain access to the Derby jira issue tracker as per https://db.apache.org/derby/DerbyBugGuidelines.html#Login+to+Jira%2FRequest+a+Jira+userid (I tried the self-sign-up way but that doesn't have Derby in the project list.)
The point of this challenge is to also update the TCK to acknowledge that Character[]/Byte[] can better map to SQL ARRAY type due to null support.
I think we should consider updating Persistence 3.1 TCK tests to not fail with persistence providers that support
SQL Arraymapping.As per https://jakarta.ee/committees/specification/tckprocess:
Persistence Providers that support mapping SQL Array types to Character[] or Byte[] Java fields may see failures like in the attached jtrfiles.zip
I will propose a Platform TCK
10.0.xpull request for changing the related tests which may involve the following files:The same files as above are returned for grep -rl "Byte.*[]"