GH-33592: [C++] support casting nullable fields to non-nullable if there are no null values

[NickCrews]

• GitHub Issue: [Python] Cannot cast nested nullable field to not-nullable #33592

Notes for myself/fixer:

• tests that need to get updated (almost definitely not a complete list)
• hmm, looks like go wrapper does its own nullability checks. I assume this is just an optimization to not have to go into the C++ and hit the error down there. So if we just delete this check then I think the C++ logic will handle all of it???
• how the plain column handles this cast, some logic like this probably needs to get ported over to the struct implementation
• cmake .. --preset ninja-debug-basic, then cmake --build ., then ctest -j16 --output-on-failure to run all tests, or ctest -R 'arrow-compute-scalar-cast-test' to run the specific one

[github-actions]

Thanks for opening a pull request!

If this is not a minor PR. Could you open an issue for this pull request on GitHub? https://github.com/apache/arrow/issues/new/choose

Opening GitHub issues ahead of time contributes to the Openness of the Apache Arrow project.

Then could you also rename the pull request title in the following format?

GH-${GITHUB_ISSUE_ID}: [${COMPONENT}] ${SUMMARY}

or

MINOR: [${COMPONENT}] ${SUMMARY}

In the case of PARQUET issues on JIRA the title also supports:

PARQUET-${JIRA_ISSUE_ID}: [${COMPONENT}] ${SUMMARY}

See also:

• Other pull requests
• Contribution Guidelines - Contributing Overview

[github-actions]

⚠️ GitHub issue #33592 has been automatically assigned in GitHub to PR creator.

[rustyconover]

This PR looks pretty good to me, what additional help would you like getting it merged?

[NickCrews]

Thanks for the help! I'm a random contributor, so I'm not sure about the exact workflow, but I think both getting the CI run approved and having a C++ owner approve it are needed.

Any more detailed thoughts on if the tests are adequate, if there's anywhere else in the code base that you think needs to change, my handling of the go implementation by just deleting the shortcircuit, or any other more detailed thoughts? Basically anything that would reduce the mental load on the code owner I think would increase the odds they approve it :)

[mapleFU]

You can mark as ready for review? Or this is still wip?

[NickCrews]

Oops, didn't mean for this to still be marked WIP. Looks like a few failures that need to get fixed, but still a high-level review of the general approach would still be appreciated in the meantime.

[zeroshade]

You probably need the same corresponding check on the Go side to verify that it's only allowed if there are no nulls.

Also, the Go implementation has been moved to the apache/arrow-go repository. So please file the PR there for the Go side. Sorry for the confusion, we just haven't removed the Go code from here yet.

[NickCrews]

Thanks @zeroshade , will do. Do we need both PRs to land at about the same time, or can I do that independently?

I will undo my changes to the go code here, leaving it untouched.

[zeroshade]

They can land independently, no issues there. Thanks!

[NickCrews]

Just pushed a new version:

• dropped the Go changes
• rebased on top of 3600db8, which is one commit behind main, because main is failing CI, but the commit I chose passed CI. I did this because I think the failing CI checks in this PR are not related to this PR
• I discovered archery and formatted the files with archery lint --clang-format --fix

We will see if this passes CI now...

[NickCrews]

Pushed a new version, hopefully that fixed the broken tests:

• To go from nullable to non-nullable type, need to use the unsafe cast option
• fix typo of int8 to int64 so the precision matches
• removed the [Go] tag from the commit message

[NickCrews]

@zeroshade I think this is ready to review/merge, the failing CI runs look like flakes when trying to setup the environment?

[kou]

Can we move this to apache/arrow-go?

[kou]

Ah, the Go part was removed from this PR.
I've removed "[Go]" from the PR title.

[NickCrews]

Those CI failures look unrelated? Not sure, CI history looks pretty flaky to me.

[----------] 1 test from LargeRowEncryptionTest
[ RUN      ] LargeRowEncryptionTest.ReadEncryptLargeRows
/arrow/cpp/src/arrow/dataset/file_parquet_encryption_test.cc:159: Failure
Failed
'_error_or_value28.status()' failed with IOError: AesDecryptor was wiped outDeserializing page header failed.

/arrow/cpp/src/arrow/dataset/file_parquet_encryption_test.cc:265: Failure
Expected: TestScanDataset() doesn't generate new fatal failures in the current thread.
  Actual: it does.
[  FAILED  ] LargeRowEncryptionTest.ReadEncryptLargeRows (49 ms)
[----------] 1 test from LargeRowEncryptionTest (49 ms total)