fix: support arrow views in ensure_data_types

[zachschuermann]

What changes are proposed in this pull request?

We landed support for Arrow view types in #533 but didn't make modifications to ensure_data_types, meaning users would hit Incorrect datatype. Expected string, got Utf8View

This adds:
kernel's BINARY = BinaryView
kernel's STRING = Utf8View
kernel's Array = ListView
kernel's Array = LargeListView
(and ran across a missing LargeList equivalence, so added:)
kernel's Array = LargeList

How was this change tested?

new UT

resolves #1027

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 84.77%. Comparing base (4a13e74) to head (dc7b246).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1028      +/-   ##
==========================================
+ Coverage   84.74%   84.77%   +0.02%     
==========================================
  Files          92       92              
  Lines       23407    23450      +43     
  Branches    23407    23450      +43     
==========================================
+ Hits        19836    19879      +43     
  Misses       2587     2587              
  Partials      984      984              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[nicklan]

LGTM, thanks for the fix

[nicklan]

Why do we need debug and clone? It does have a compile time cost, so I prefer to add it only when needed. Also, if the eq/partialeq are just for tests, can we only derive it if testing? (not sure how easy/possible that is)

[zachschuermann]

yea fair point - I derived Debug since it seems like something you should almost always do even if only for testing/println debugging. I can remove clone/eq! and let me know if you think it's worth doing cfg(test) only

[zachschuermann]

actually yea i think it makes sense - doing test-only :)

[scovich]

The specific change looks fine, but --

How much does schema checking actually help, if the default engine's arrow eval doesn't actually handle those types? Do we need to add that support in this PR as well? Or is that something to look into as a fast-follow?

[scovich]

Would it be better to explicitly capture the 1:many relationship here?

Suggested change

	(&DataType::BOOLEAN, ArrowDataType::Boolean)
	| (&DataType::STRING, ArrowDataType::Utf8)
	| (&DataType::STRING, ArrowDataType::Utf8View)
	| (&DataType::BINARY, ArrowDataType::BinaryView)
	| (&DataType::BINARY, ArrowDataType::Binary) => Ok(DataTypeCompat::Identical),
	(&DataType::STRING, ArrowDataType::Utf8 | ArrowDataType::Utf8View)
	| (&DataType::BINARY, ArrowDataType::Binary | ArrowDataType::BinaryView)
	| (&DataType::BOOLEAN, ArrowDataType::Boolean) => Ok(DataTypeCompat::Identical),

[scovich]

Similar to the above -- there's a lot of redundancy here

Suggested change

	(DataType::Array(inner_type), ArrowDataType::List(arrow_list_field))
	| (DataType::Array(inner_type), ArrowDataType::LargeList(arrow_list_field))
	| (DataType::Array(inner_type), ArrowDataType::ListView(arrow_list_field))
	| (DataType::Array(inner_type), ArrowDataType::LargeListView(arrow_list_field)) => {
	(
	DataType::Array(inner_type),
	ArrowDataType::List(arrow_list_field)
	| ArrowDataType::LargeList(arrow_list_field)
	| ArrowDataType::ListView(arrow_list_field)
	| ArrowDataType::LargeListView(arrow_list_field),
	) => {

Not sure whether the deeper match is actually better than the flattened one tho?