gianm commented on issue #8242: should we deprecate extractionFn field in various Aggregators and Filters URL: https://github.com/apache/incubator-druid/issues/8242#issuecomment-518756546 IMO if the deprecation cycle is long-ish (multiple release cycles) and generally aligned with moving most users to SQL then it makes sense to me. The thoughts guiding me here are: - ExtractionFns are generally a nicer API for users writing native queries manually than virtual columns. - If most users that write queries manually switch to SQL, then the above point doesn't matter, since it's handled by the SQL layer. - Virtual columns are probably a nicer API for users that write native queries programmatically. - Getting rid of ExtractionFns on DimensionSpec and DimFilter interfaces would simplify the implementations, which is great. We would need to review to make sure we aren't losing any efficiency (this is a nice test of how good the VirtualColumn interface is). - Druid users that have already written integrations based on extractionFns are going to have a hard time upgrading to a Druid version that removes them. The feature has been around for a long time and is widely used, so we should give people a generous amount of time to migrate off. - A compatibility layer could be useful, it would be very user-friendly but complicate the implementation. Would it be worth the de-complexification of removing the need for individual filters, dimension specs, selectors, etc, from needing to worry about extractionFns? I'm not sure now, but it might be. If so I would consider it. If not then probably just do a long deprecation cycle. We could consider getting rid of the `expression` field on AggregatorFactories too. Similar observations apply.
---------------------------------------------------------------- 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. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
