ARROW-16677: [C++] Support nesting of function registries

[rtpsw]

Currently, only a default function-registry is supported. Modifying this registry has global effects, which is often undesirable. Support for nesting function-registries will provide scoping for such modifications.

[github-actions]

https://issues.apache.org/jira/browse/ARROW-16677

[github-actions]

⚠️ Ticket has not been started in JIRA, please click 'Start Progress'.

[rtpsw]

cc @icexelloss

[rtpsw]

This proposed feature, along with the one in #13232 , would enable scoping for all registries used for UDFs.

[rtpsw]

@westonpace - could you review?

[westonpace]

I think we can simplify this a bit but this looks useful.

[westonpace]

Sorry, picked the wrong radio bubble :)

[rtpsw]

Looks like the failed jobs are not due to the changes here.

[rtpsw]

@westonpace, is this good to go?

[westonpace]

Most of these changes are minor but we do need to clean up the constructors.

I realized as I was doing the review that some of these method comments (e.g. \brief) were following existing patterns in this file. However, I think the suggestions move us more in line with the rest of the code base (e.g. \brief should be a one line description. The things that follow are a note) and we can clean up the others later.

I find the nested ternary (i.e. (a ? b : c) & d a little too compact to follow. Now that Status && Status is unavailable I think we should probably avoid & when short-circuit is desired when using Status.

It might be worth noting somewhere (assuming my understanding is correct here) that even if allow_overwrite is true it a registry will never modify its parent.

Lastly, I'm not sure why we didn't check for existing function names in AddAlias. I think we should probably correct that here rather than persist the status quo. But it's possible I'm not understanding some nuance.

[westonpace]

Suggested change

	new FunctionRegistry(new FunctionRegistry::FunctionRegistryImpl(&*parent->impl_)));
	new FunctionRegistry(parent->impl_.get());

The way it is currently will create a copy of the parent. This pointer leaks but, more importantly, if you did something like...

auto parent = GetFunctionRegistry();
auto nested = FunctionRegistry::Make(parent);
// The function added here (using parent) will not be visible by nested
// and, if I'm understanding the purpose correctly, we would want that
parent->AddFunction(...);

Instead we should just take a non-owning "view" pointer to the parent. If the parent is deleted before the nested registry is deleted then bad things will happen but that is to be expected.

[rtpsw]

This change leads to a failed test:

/mnt/user1/tscontract/github/rtpsw/arrow/cpp/src/arrow/compute/registry_test.cc:124: Failure
Failed
'default_registry->CanAddFunction(func)' failed with Key error: Already have a function registered with name: f1
[ FAILED ] TestRegistry.RegisterTempFunctions (0 ms)

The existing code makes a new FunctionRegistryImpl with a parent of the same type, which is what we want for scoping. Though I did fix this code to use .get().

[rtpsw]

Most of these changes are minor but we do need to clean up the constructors.

I realized as I was doing the review that some of these method comments (e.g. \brief) were following existing patterns in this file. However, I think the suggestions move us more in line with the rest of the code base (e.g. \brief should be a one line description. The things that follow are a note) and we can clean up the others later.

I find the nested ternary (i.e. (a ? b : c) & d a little too compact to follow. Now that Status && Status is unavailable I think we should probably avoid & when short-circuit is desired when using Status.

It might be worth noting somewhere (assuming my understanding is correct here) that even if allow_overwrite is true it a registry will never modify its parent.

Lastly, I'm not sure why we didn't check for existing function names in AddAlias. I think we should probably correct that here rather than persist the status quo. But it's possible I'm not understanding some nuance.

I agree with almost everything. I think your comments about logic are not minor :) I ended up fixing and cleaning up the code quite a bit following them. Thanks for catching.

[westonpace]

This is ready to go. Thanks for that last round of cleanup. I think there is some overlap now with what is in #13375. Shall I merge this first and let you merge this into #13375? Or would you rather hold off and merge everything all at once as part of #13375?

[rtpsw]

This can get pushed and I'll handle the merge.