jonkeane commented on pull request #12467: URL: https://github.com/apache/arrow/pull/12467#issuecomment-1075158797
Aaaah, yeah I totally missed `register_extension_type()` oops! Though weirdly(?) the `as.vector()` here is still wrong, it should be `1 2 3` (since the ->R conversion on this Extension type should have 1 added to it) ``` # you need to register the type for Arrow C++ to keep the extension type # slash metadata when it encounters it at the C++ level (import from C # and reading files) register_extension_type(korean_age()) tf <- tempfile() write_feather(arrow_table(col = arr), tf) tab <- read_feather(tf, as_data_frame = FALSE) type(tab$col) #> KoreanAge #> KoreanAge <Korean Age, but stored as the western age value> as.vector(tab$col) #> [1] 0 1 2 ``` > I should probably export ExtensionArray and use ExtensionArray$create() rather than new_extension_array() since it's more arrow-ish to do that. In other places we've exposed both, which I think isn't bad here (it's slightly more API we manage, but having the R6 stuff exposed makes it easier to extend, and having the `foo_bar_baz` looks nicer | is a bit more friendly to users|doesn't force someone to learn all the R6 if what they want or need is available there)... > Maybe ExtensionType$create() instead of new_extension_type() is where extension type creation should go, too. Hmm, if we think it's ok to do the `new_extension_type()` inside of `ExtensionType$create()` I would agree that having a second step like that is unnecessary. Though with the proper docs having the R6 way of establishing these need to be slightly more verbose and you need to manage other things is inline with our other implementations of things like that (e.g. creating one's own filesystem, etc.) -- 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]
