cmettler commented on PR #284: URL: https://github.com/apache/arrow-dotnet/pull/284#issuecomment-4916611450
> > My instinct is follow-up — this PR is large enough — but happy either way. > > I think that makes sense. > > > extension columns don't rehydrate after `ArrowStreamReader` > > Can you clarify this with a specific code sequence? There are constructors which take an `ArrowContext`, and my intent was that code opts into extension types during IPC deserialization by supplying one with the expected types configured. (Of course, it's been about four months and the details have long since been GC'd :/.) I took a four-month detour through a wormhole and it turns out the exit is much harder to find than the entrance... You're right, and I'd missed that ArrowContext already does exactly this — thanks for pointing me back to it. Rather than the module-initializer approach I'd sketched, I've reworked it to follow the JsonSerializerOptions/MessagePack MessagePackSerializerOptions pattern in a followup PR: an ArrowSerializerOptions with a Default (an ArrowContext that has the uuid and variant extensions registered) that the byte/stream helpers use when none is passed, plus the ability to supply your own — ArrowSerializerOptions.Default.WithExtensions(new MyExtensionDefinition()) or a fully custom context. So extension resolution is opt-in via the context exactly as you intended, and nothing mutates ExtensionTypeRegistry.Default. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
